Assembler debug window

[caleb9]

Hi, I'm looking for some clarification on what does it mean when I get access violation exception (External: EXC_BAD_ACCESS), and the debugger - instead of going to a specific line in the code - opens up an Assembler window. I've been looking around google and here and couldn't figure what can be the reason for this. Does it happen when the exception occurred in one of the external functions? I have no idea about assembly programming and I'm trying to localize a bug in my project for quite a while now without success :(.

[Martin_fr]

It happens when the debugger couldn't find the source.

That could be code in an external dll/library. Or it could be code in a unit that has no debug info.

IIRC the debugger even tries to find the calling function (the closest one, for which there is line info).
However some times the stack is not readable, then no such line can be found.

You can always try to see if the stack window will show something useful.
But often in situations like this it will only show a few cryptic entries.


Ensure your setup is correct:
http://wiki.lazarus.freepascal.org/Debugger_Setup

Also ensure you got the latest gdb 7.3.2:
http://svn.freepascal.org/svn/lazarus/binaries/i386-win32/gdb/bin

Which version of Lazarus do you use? 0.9.30.1 has various fixes over 0.9.30

Also use -Cr -Ct -Ci -gh -gt

In the worst case you have to narrow it down from the other end:
Single step (step-over F8) the code you suspect it to happen. Then when it crashes you may have just stepped over a function. Repeat, but this time step into the function. Repeat until you find the code that causes the issue.

[caleb9]

Thanks. I'll try your suggestions but what I can say immediately is that I'm using Lazarus from SVN but unfortunately I'm using it on Mac OS X, which means that my gdb is 6.3.50 from (new) XCode (about 7 years old by now - sic!) - despite many tries I didn't make it to run gdb-7.x from macports (or it runs but not well with Lazarus)... I'll get back when I try other stuff you suggested.

[caleb9]

Ok, so I've had "Link Smart (-XX)" enabled in Linking options. But I'm not sure that this was the actual problem. Turned out it was the messed up project file which strove to keep in sync with corresponding Delphi .dpr file (unfortunately I have to deal with a single codebase which is suppose to compile on both), namely Lazarus .lpr file only included ({$I}) the Delphi .dpr file. When I separated the two and generated a standard Lazarus .lpr, the debugger magically started to go to the code instead of assembler when crashed. It's by pure accident that I discovered this and probably it cannot help anyone with similar problems, nevertheless I think - for now - it is solved in my case...

[Martin_fr]

I can not answer much about the dpr issue.

But you can start lazarus with --debug-log=C:\lazlog.txt

Then you can see if the compiler-options are the same for the synced and unsynced project files.

Sounds as if debug info wasn't generated correctly.

It could also be your path. If any of the tools used by fpc, where taken from the delphi installation.
Delphi does a different debug format, so that may interfere with stabs/dwarf.
Though I do not know if there would be anything that could have been called. If the -Xe option was used, then ld.exe (external linker). But it had to be present in delphi too.
Same if you specify external assembler....

[caleb9]

Well yeah, the problem reappeared. Seems it was not the .lpr/.dpr after all - I have now a separate .lpr file for lazarus which doesn't include the .dpr but the problem still occurs.
Can you please clarify what do you mean by tools in "If any of the tools used by fpc, where taken from the delphi installation."?

[Martin_fr]

I don't think your Delphi install will interfere with normal compilation.

afaik, the problems are with tools like make.exe (which Delphi has a different version of). So if the Delphi version is in the environment %PATH  var, then problems can arise.

I don't know if Delphi as a ld.exe (linker), but at any rate that would only matter if you used -Xe

[Martin_fr]

Maybe the error happens in a library, or code without debug (like the RTL).

what is the stack window showing?

[caleb9]

I don't think your Delphi install will interfere with normal compilation.

afaik, the problems are with tools like make.exe (which Delphi has a different version of). So if the Delphi version is in the environment %PATH  var, then problems can arise.

I don't know if Delphi as a ld.exe (linker), but at any rate that would only matter if you used -Xe

That would be true if I used Lazarus on Windows, yes. But I'm on Mac, where there's no Delphi installed. Anyway seems that in this particular situation it has something to do with a buggy code manually setting Parent property to bunch of components, which have to be moved around different forms. I tried to emulate the situation in a test program and when I assigned Parent := nil I got the same error. The mysterious part is that sometimes it directs me to code, somewhere in Carbon (Mac OS widgetset) implementation, and sometimes it goes to assembler. Thinking of it now it actually might mean they're two different bugs, difficult to track since sometimes they occur, sometimes not. So far I've been unable to notice any regularity in it, since I'm rebuilding FPC and Lazarus (both from SVN) with different packages and stuff all the time . I'll get back if any new discoveries pop up.