Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2009-11

Lazarus debug issues

4 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

ik

Hello list,

Recently I've written a console application using Lazarus. It had an Access violation, and why gdb (that I used on my own) told me about one line, when I execute it on Lazarus, Lazarus pointed on a different line. It just happen that Lazarus pointed on the line where i should have initialized the variable (but instead just made an "empty" initialization), while GDB pointed on the point I used the non initialized variable.

So my question is, how did Lazarus knew to point on the proper line that was not the same line as GDB's ?

Thanks,
Ido

http://ik.homelinux.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091109/bcad0774/attachment.html>

Reply by email

JoshyFun
to ik

Hello Lazarus-List,

Monday, November 9, 2009, 9:21:56 AM, you wrote:

i> Recently I've written a console application using Lazarus. It had an Access i> violation, and why gdb (that I used on my own) told me about one line, when i> I execute it on Lazarus, Lazarus pointed on a different line. It just happen i> that Lazarus pointed on the line where i should have initialized the i> variable (but instead just made an "empty" initialization), while GDB i> pointed on the point I used the non initialized variable. i> So my question is, how did Lazarus knew to point on the proper line that was i> not the same line as GDB's ?

GDB and Lazarus (well, fpc) sometimes does not agree about the line to be shown, sometimes the debugged line is one line below so you are watching in Lazarus the previously executed line.

This effect seems to be some kind of misunderstood between fpc debug info and gdb (gdb 7.0 seems to be more precise in this field) but I was unable to find the gilty of such behavior.

This could also happend when you do not full recompile the code and debug an ".inc" file, as this file may had not been recompiled at all because the ".pas" one was not modified.

Check the "debugger output window" for the returned line number on each step, you'll find it at the end of the last line.

Best regards, JoshyFun

Reply by email

David Emerson
to JoshyFun
JoshyFun wrote
This could also happend when you do not full recompile the code and debug an ".inc" file, as this file may had not been recompiled at all because the ".pas" one was not modified.

I believe this is alleviated when the inc file is properly added to the project or package, via the project inspector or package dialog.

~David.

Reply by email

JoshyFun
to David Emerson

Hello Lazarus-List,

Monday, November 9, 2009, 7:30:12 PM, you wrote:

JoshyFun wrote
> This could also happend when you do not full recompile the code and > debug an ".inc" file, as this file may had not been recompiled at all > because the ".pas" one was not modified.

DE> I believe this is alleviated when the inc file is properly added to the DE> project or package, via the project inspector or package dialog.

Hmmm... yes if the file is in the project it could work, but how to know in which ppu the changes should reside ? Maybe checking all the ppus.

Best regards, JoshyFun

Reply by email