Board index » cppbuilder » Stepping thru source code

2004-02-04 04:39:53 PM
cppbuilder48
I see at least three other recent posts about the problem of people not
being able to step into DLL source code while debugging with diffrent
version of BCB. It makes me wonder if it might have anything to do with OS
changes.
 

"Jim Melsom" < XXXX@XXXXX.COM >wrote in message
since it handles DLLs differently then previous OS versions.
Gambit
 

through a dll only happens randomly, I have tried all
the setting and it doesn't make any difference.
Someone I work with is using BCB6 under WinXP
and has the same problems as me, so I don't think
it is the OS so much as BCB.
 

{smallsort}

"Jim Melsom" < XXXX@XXXXX.COM >wrote in message
is an address collision with another process.
As shown already, one way to work around the problem is to use Ctrl-Alt-M to
manually re-load the DLL(s) you need to step into. An alternative, more
automatic solution, is to change the image base addresses of your DLL(s) to
be more or less unique (the project linker options always defaults to
0x400000). Changing the image's base address reduces the chance of
collision with other processes, and increases the liklihood that the DLL
will load without relocation (when you run your application from the IDE,
watch the "Event Log" -- it will tell you when DLL's are relocated due to
collisions, and what address it attempted to use that caused the collision).
If you do this, choose addresses between 0x60000000 and 0x70000000 (it's a
safe range to use for all Windows OSes). Leave at least a 0x100000 (1MB)
range between addresses to help avoid overlap. If you have a very large DLL
or EXE (1-2 MB), you will want to leave a 0x200000 (2MB) range open for it.
As a side benefit, if your application uses lots of DLL's, the reduction in
address collisions will allow your application load a fair bit faster
because Windows won't have to spend time searching for where it can relocate
them.
- Dennis
 

This happens to me fairly often on Win2k. The only work-around I have found
is to reboot, then do a full rebuild of all libraries and executables. That
has almost always solved the problem for me, at least for awhile until the
next time.
Tim
 

"Dennis Jones" < XXXX@XXXXX.COM >wrote in
Jim