🚀 go-pugleaf

Colin B Maharaj wrote:

>Hi all, I need to generate a map file to help me trap an access 
>violation in a multi-threading TCP application I am working on.

The debugger will take you to the appropriate line, given the address.
The line number info is encoded in the tds file.

>The thing is that I would also like to have the map file contain
>line numbers but this does not seem to be happening. I set the project
>to generate map files and no other apparent option is available to 
>create line numbers as well.

See an older thread.
From: hgiese@ratiosoft.com (Helmut Giese)
Newsgroups: borland.public.cppbuilder.commandlinetools
Subject: How to relate code address to line in source code?

I wonder if Helmut ever figured it out.

On Mon, 19 Jun 2006 11:02:28 -0700, Bob Gonder
<notbg@notmindspring.invalid> wrote:

>See an older thread.
>From: hgiese@ratiosoft.com (Helmut Giese)
>Newsgroups: borland.public.cppbuilder.commandlinetools
>Subject: How to relate code address to line in source code?
>
>I wonder if Helmut ever figured it out.
Well, he did. :)

Hi Bob,
you maintain an impressive collection of links.

For the sake of the OP (or anybody else interested in this): It's
possible, but it's a _lot_ of work.

First I tried analyzing the .obj files. I had found some documentation
but it turned out to be insufficient. Basically an .obj file consists
of a suite of blocks which are structured like this:
- 1 byte: key (what type of block)
- 2 bytes: size of data to follow
- n bytes of data

So you hop along analysing the content of each block according to its
type. But invariably at some point the sequence seemed broken. Well,
it couldn't really be broken, because the linker knows how to handle
those .obj files, but the sequence didn't make sense:
- you found an unknown type or
- the size was impossible (leading beyond the actual file size)

So after a week of frustrating work (ever stared at binary data trying
to grok its structure?) I gave up.

There was another road to try out: bordebug.dll. It contains functions
which know to analyse a .tds file - but be warned: it is no joy to
work with.
But if anybody wants to go this route: Get a copy of Delphi Magazine
Issue 63. It contains an article "The return of the giant" which
presents a tool (in Delphi, of course) which uses bordebug.dll to show
you all kinds of information.
The sources are available online but the article _really_ helps. I
strongly suggest investing those 7 British Pounds to get a copy.

But still a last warning: You should have an exceptional need if you
think you need this kind of information - something like building your
own debugger - otherwise the investment in time is ridiculously large
wrt to the actual gain.
We did have such a need - don't ask, the project has been put on hold,
otherwise I would take this chance to brag about what a great guy I am
tackling this chore :)

Bob, somehow you put me into talking mode. Ok, now you know more about
this topic than you probably ever wanted to. :)
Have a nice time
Helmut Giese

> ...There was another road to try out: bordebug.dll...

I just looked and could not find a bordebug.dll.  Where did you find it?

> ... ever stared at binary data trying to grok its structure? ...

Do I detect a Heinlein fan?

.  Ed

> Helmut Giese wrote in message
> news:4497e6bb.1714921@forums.borland.com...
>
> First I tried analyzing the .obj files. I had found some
> documentation but it turned out to be insufficient. Basically
> an .obj file consists of a suite of blocks which are structured
> like this:
> - 1 byte: key (what type of block)
> - 2 bytes: size of data to follow
> - n bytes of data
>
> So you hop along analysing the content of each block according
> to its type. But invariably at some point the sequence seemed
> broken. Well, it couldn't really be broken, because the linker
> knows how to handle those .obj files, but the sequence didn't
> make sense:
> - you found an unknown type or
> - the size was impossible (leading beyond the actual file size)
>
> So after a week of frustrating work (ever stared at binary data
> trying to grok its structure?) I gave up.
>
> There was another road to try out: bordebug.dll. It contains
> functions which know to analyse a .tds file - but be warned: it
> is no joy to work with.
>
> But if anybody wants to go this route: Get a copy of Delphi
> Magazine Issue 63. It contains an article "The return of the
> giant" which presents a tool (in Delphi, of course) which uses
> bordebug.dll to show you all kinds of information. The sources
> are available online but the article _really_ helps. I strongly
> suggest investing those 7 British Pounds to get a copy.
>
> But still a last warning: You should have an exceptional need
> if you think you need this kind of information - something like
> building your own debugger - otherwise the investment in time
> is ridiculously large wrt to the actual gain.

Hi Ed,
>> ...There was another road to try out: bordebug.dll...
>
>I just looked and could not find a bordebug.dll.  Where did you find it?
it comes as part of the download from the Delphi Magazine site
(dmag63.zip) and a readme therein says
	---
14513
=====

This is the Borland CodeCentral download #14513
bordebug.dll		The API DLL from Borland
bordebug.h		The C header file
	---
which is probably where I got it in the first place.

Ok, as a small service I just had a look at Borlands site:
http://codecentral.borland.com/Item.aspx?id=14513
brings you right to the respective download page - but they want you
to log in (as you probably know).

>> ... ever stared at binary data trying to grok its structure? ...
>
>Do I detect a Heinlein fan?
You're very observant. Yes, and a big one to boot - my absolute
favourite being Stranger In a Strange Land. I had it in English,
French and German - the German edition being lousy: The page count was
about 2/3 of the original - and if you consider that German words are
(on average) longer than their English counterparts so that any
reasonable translation from English to German usually increases the
size - well, you get an idea.
Of course, now that I come to think of it, it's been years - _many_
years even, that I didn't re-read any of his works. Hm, maybe some
evening(s) this summer will offer an opportunity.
.
Hey, Ed, thanks a lot for putting this idea into my mind. :)
Best regards
Helmut Giese

Ed Mulroy wrote:
>> ...There was another road to try out: bordebug.dll...
> 
> I just looked and could not find a bordebug.dll.  Where did you find it?

"Borland Debug Hook Library and Header File"
http://codecentral.borland.com/Item.aspx?id=14513

> Ok, as a small service I just had a look at Borlands site:
> http://codecentral.borland.com/Item.aspx?id=14513
> brings you right to the respective download page - but
> they want you to log in (as you probably know).

Thanks - I never knew that John Thomas posted that.

FYI: I just downloaded it from there.  No login.  No idea why your 
experience was different.  It came in with the impossibly long name of
14513_borland_debug_hook_library_and_header_file.ZIP

> .... my absolute favourite being Stranger In a Strange Land...

I grew up reading Heinlein.  A lot of his stuff was for kids and as a kid I 
got his books from the library and devoured them.  When Stranger in a 
Strange Land came out it absolutely blew me away.  Except for Glory Road, 
The Number of the Beast and the unfinished first novel that they posted on 
the Internet recently (didn't keep a link) I like everything he wrote.

.  Ed

> Helmut Giese wrote in message
> news:449832fc.21238642@forums.borland.com...
>
>>I just looked and could not find a bordebug.dll.  Where did you find it?
>
> it comes as part of the download from the Delphi Magazine site
> (dmag63.zip) and a readme therein says
> ---
> 14513
> =====
>
> This is the Borland CodeCentral download #14513
> bordebug.dll The API DLL from Borland
> bordebug.h The C header file
> ---
> which is probably where I got it in the first place.
>
> Ok, as a small service I just had a look at Borlands site:
> http://codecentral.borland.com/Item.aspx?id=14513
> brings you right to the respective download page - but they want you
> to log in (as you probably know).
>
>>> ... ever stared at binary data trying to grok its structure? ...
>>
>>Do I detect a Heinlein fan?
> You're very observant. Yes, and a big one to boot - my absolute
> favourite being Stranger In a Strange Land. I had it in English,
> French and German - the German edition being lousy: The page count was
> about 2/3 of the original - and if you consider that German words are
> (on average) longer than their English counterparts so that any
> reasonable translation from English to German usually increases the
> size - well, you get an idea.
> Of course, now that I come to think of it, it's been years - _many_
> years even, that I didn't re-read any of his works. Hm, maybe some
> evening(s) this summer will offer an opportunity.
> .
> Hey, Ed, thanks a lot for putting this idea into my mind. :)

Thanks.  I've no idea how I missed knowing about that debug library.

.  Ed

> Darko Miletic wrote in message
> news:44984ac3@newsgroups.borland.com...
>
>> I just looked and could not find a bordebug.dll.  Where did you find it?
>
> "Borland Debug Hook Library and Header File"
> http://codecentral.borland.com/Item.aspx?id=14513

Hi Colin,
>Hi Bob, thanks for your response. Whats really
>happening is that the access violation is happening
>at a customer's site and not in my test environments.
this may or may not help you, but Copilot
	 https://www.copilot.com
is a novel way to do customer support, e.g. they circumvent any
potential firewall issue.
Using it you could get complete access to the client's machine and
thus maybe get more information than the client providing them.
 
>
>Thus I need to get the access violation address that
>is seen at the customer screen and use this to backtrack
>the function (which I can do) just this function can be called
>anywhere...
>
>My next obvious question is what's the format of the tds file
See my answer to Bob's posting - but I cannot really encourage you.
HTH
Helmut Giese

Hi Bob, thanks for your response. Whats really
happening is that the access violation is happening
at a customer's site and not in my test environments.

Thus I need to get the access violation address that
is seen at the customer screen and use this to backtrack
the function (which I can do) just this function can be called
anywhere...

My next obvious question is what's the format of the tds file

:) :)

But I know that's probably not public...




Bob Gonder wrote:
> Colin B Maharaj wrote:
> 
>> Hi all, I need to generate a map file to help me trap an access 
>> violation in a multi-threading TCP application I am working on.
> 
> The debugger will take you to the appropriate line, given the address.
> The line number info is encoded in the tds file.
> 

Colin B Maharaj wrote:

>happening is that the access violation is happening
>at a customer's site and not in my test environments.
>
>Thus I need to get the access violation address that
>is seen at the customer screen and use this to backtrack
>the function (which I can do) just this function can be called
>anywhere...

Sounds like you need to get the customer to create and send you the
crash report that the access violation can create.

You then fire up the debugger on your end, and plug in the addresses
in CPU view. Takes you right to the line. Then look at the stack
report and try to trace back to the caller.

As a last resort, use your own version of ASSERT() in the offending
function to dump the information for you (and not violate access).

Colin B Maharaj wrote:
> Hi Bob, thanks for your response. Whats really
> happening is that the access violation is happening
> at a customer's site and not in my test environments.

I'd highly recommend downloading EurekaLog from 
http://www.eurekalog.com/index.php. It'll give you everything you'll need to 
know about the AV.

HTH

Jonathan
-----------------------------------------------------------------
TwineCompiler - Blazingly fast C++ compiles on ANY machine.
http://www.jomitech.com/#twine
----------------------------------------------------------------- 

Jonathan Benedicto wrote:
> I'd highly recommend downloading EurekaLog from 
> http://www.eurekalog.com/index.php. It'll give you everything you'll need to 
> know about the AV.

Yep. EurekaLog is the way to go. It produces extremely detailed output 
with line numebrs on any exception. It is even more detailed than .NET 
exceptiondialog :)