Hello,
I'm trying to debug a strange crash in an application (it's strange because the exception dialog appears and then disappears almost instantly without clicking on any button, so the customer cannot tell me the reason of the exception).

My application (as almost any application I write) is based on the assumption that methods invoked by a timer and methods invoked by a thread with synchronize will never fire at once (i.e. they will be serialized by the main loop).

Can I be 100% sure of that?
I'm currently using an old version of lazarus (svn 22953 dated 2009-12-04) with fpc 2.2.4.

Bye

widgetset ?

zeljko

En/na zeljko ha escrit:

win32 in this case (but I'd also like to be sure for other widgetsets).

Bye

Yep.

If the LCL would not do this this would be a bug. Timer events, synchronized events, "procedure ... message" Events fired by "PostMessage()" in a thread and Events fired by
Application.QueueAsyncCall are to be serialized and handled in the main thread and thus don't preempt the usual handlers that are fired by normal GUI events.

I did encounter other bugs with synchronize etc, but not a bug that results in handling an event in another thread.

-Michael

For completeness:
If the main thread calls Synchronize then the method will be called instantly.

Mattias

Mattias Gaertner wrote

If the main thread calls Synchronize then the method will be called instantly.

Yep, But of course this does not result in any preemption, either.

-Michael

En/na Luca Olivetti ha escrit:

I added as an Application exception handler the code from

http://wiki.freepascal.org/Logging_exceptions#Dump_exception_call_stack

(modified to dump it to a file instead of showing the message).

They managed to provoke the crash (I cannot on my development machine) and sent me the file:

31/01/2011 10:23:26 TApplication EListError List index (3) out of bounds Stack trace:
$0043FEFF

There are two problems with that:

1) there's no debug information (though the exe has full debug information and the "Dump current call stack" function shows complete debug information)

2) there's no real stack trace, so I cannot pinpoint where my application causes the crash

For 1) I used gdb

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-mingw32"...
(gdb) info line *0x0043FEFF
No line number information available for address
0x43feff <CLASSES_TFPLIST_$__RAISEINDEXERROR$LONGINT+15> (gdb)

that doesn't really help me without a solution for 2)

Any hint?

Bye

Al 01/02/11 09:07, En/na Luca Olivetti ha escrit:

Nobody has an idea on why an application would crash without a stack trace? Memory overwriting/corruption perhaps?

Bye

Luca Olivetti wrote

Al 01/02/11 09:07, En/na Luca Olivetti ha escrit: > 31/01/2011 10:23:26 TApplication EListError List index (3) out of bounds > Stack trace: > $0043FEFF

That code is in the RTL, and that may for various reasons not always dump correctly.
For me generally it helps, if the rtl itself is recompiled with debug info.

Make sure to use the same kind of debug info stabs="-g -gl" or dwarf="-gw -gl" than for the rest of your app, and the LCL, and all included package (so long as packages have dbg info, they do not necessarily all need it)

> (gdb) info line *0x0043FEFF > No line number information available for address > 0x43feff <CLASSES_TFPLIST_$__RAISEINDEXERROR$LONGINT+15> > (gdb)

Your 2nd option is to modify the RTL (at the above location), and but the stack dupm in there, before the exception is raised....

Same here.

But I regocnize that particular line, I once had an error myself exactly there... And guess what...

Martin

Al 05/02/11 16:39, En/na Martin ha escrit:

Usually I get a stack trace, even from exceptions generated in the RTL. I'll see if I manage to recompile the RTL with full debug info.

Bye

Al 05/02/11 16:48, En/na Martin ha escrit:

I'm too lazy to guess, but I suppose you didn't get a stack trace ;-) Did you recompile the rtl with debug info and then got a full stack trace? Or did you modify the function to dump the stack?

Bye

recompiled rtl with -gw -gl

Sorry I forgot, I gave to options earlier...

Al 05/02/11 17:26, En/na Martin ha escrit:

> Did you recompile the rtl with debug info and then got a full stack > trace? recompiled rtl with -gw -gl

Is it enough to do a

make clean
make OPT="-gw -gl"
make install

inside the rtl directory or should I do something else? Should I do the same for "packages"?

Bye

?

Luca Olivetti hat am 5. Februar 2011 um 16:37 geschrieben:

[...] Nobody has an idea on why an application would crash without a stack trace? Memory overwriting/corruption perhaps??

Yes, and/or stack corruption.
?

Mattias?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110205/a6681efe/attachment.html>

2011/2/5 Luca Olivetti :

See here:
http://bugs.freepascal.org/view.php?id=12528

Al 05/02/11 18:34, En/na cobines ha escrit:

Oops.
I'll try the patch in that bug report, thank you.

Bye

En/na Luca Olivetti ha escrit:

Thanks to that patch I could get a full stack trace[*], find the cause of the exception and correct my error.
Any reason why it hasn't been applied to fpc yet?

[*]addresses only, in spite of the executable having full debug and line number information[**], but I could feed those addresses to gdb to get the corresponding line numbers.

[**] If I try to dump the stack not in the exception handler (i.e, http://wiki.freepascal.org/Logging_exceptions#Dump_current_call_stack), BackTraceStrFunc correctly shows the line info, not so during the exception.

Bye

2011/2/17 Luca Olivetti :

Thanks to that patch I could get a full stack trace[*], find the cause of the exception and correct my error. Any reason why it hasn't been applied to fpc yet?

I asked recently:
http://lists.freepascal.org/lists/fpc-pascal/2011-January/027949.html

There seems to be a more general issue, which the patch doesn't fix.

[*]addresses only, in spite of the executable having full debug and line number information[**],

Did you have a different exception before that?
Maybe it is this issue:
http://bugs.freepascal.org/view.php?id=13518

En/na cobines ha escrit:

Ah, ok.

Nope, it's the only exception.

Bye

2011/2/18 Luca Olivetti :

Did you maybe run the application like this (not full path)?

./program

There's no stack trace in such a case too.

Al 20/02/11 09:08, En/na cobines ha escrit:

Then why dumping the current stack gives full line information?

Bye

2011/2/20 Luca Olivetti :

Must be something else then, because the function you mentioned doesn't give full line information for me when I run with "./program" either.

Try walking through BackTraceStrFunc, or OpenStabs, or OpenDwarf. Maybe that's a new bug.