Page 1 of 1

Call stack missing the most important line

PostPosted: Wed May 15, 2019 8:34 am
by mattes13

we currently use MadExcept 4.0.19 and C++ Builder 10.2.3. Our project has become quite large (40 - 50 MB executable).

Lately, we often have the problem, that in an exception report the most important line of the call stack is missing. We see everything fine from the windows message handler functions into our own code up to the line of our own code containing that call to foreign (e.g. Embarcadero) code again which will trigger the exception (bottom-up). This line of our own code does not show up in the call stack. The following lines (which are not our code) seem to be correct again.

Anyone had a similar problem before? It's driving me crazy as I mostly have to do detective's work again to find the function in our code with the problem. And if I know the function (because auf a log file line or exclusion principle), I still have to investigate for the line of code.

Thanks for your help and best regards!

Re: Call stack missing the most important line

PostPosted: Wed May 15, 2019 8:39 am
by madshi
Can you reproduce this issue in a brand new (almost empty) test project?

Re: Call stack missing the most important line

PostPosted: Wed May 15, 2019 8:54 am
by mattes13
I'm sorry, i cannot. The problem is that we have these exceptions very seldom compared to the number of installations and the uptime. And if they occur the circumstances are so unique that we cannot reproduce them in a simulation at home. So I usually have to guess the problem from an incomplete stack trace and some log file entries and create a workaround and hope that I hit it until I get the next bug report on my desk. It's kind of frustrating.

Re: Call stack missing the most important line

PostPosted: Wed May 15, 2019 9:35 am
by madshi
So if you raise any intentional test exceptions, you get complete callstacks?

Of course it's very hard, or next to impossible, for me to find the cause of these problems if I can't reproduce them in any way.

You could try setting "DumbStackTrace" (it's an undocumented variable exported by madExcept.pas) to TRUE in your initialization somewhere. Doing this will result in the callstacks no longer being filtered to remove "noise". With a bit of luck, maybe it brings those missing callstack lines back. However, you'll also get a *lot* more noise (invalid stack items).

Re: Call stack missing the most important line

PostPosted: Wed May 15, 2019 9:42 am
by mattes13
Thanks, I'm gonna try "DumbStackTrace" and see how much it is. Maybe, I can do this for a single installation for testing.

Re: Call stack missing the most important line

PostPosted: Wed May 15, 2019 8:01 pm
by iconic
Can you paste an incomplete stack trace you've received which you're referring to? Do you have any of them still around in log form by chance?


Re: Call stack missing the most important line

PostPosted: Thu May 16, 2019 5:54 am
by mattes13
I received this one yesterday. I've marked the line, where something is missing.
(It may take some time to get a stack trace with the Dump-Option. I will try to do some brute force testing to see, if I can reproduce it somehow, but I'm not very confident. So - most likely - I'll have to wait for an incident from on-site.)

Just one more thought: Is it possible, that it's an Embarcadero bug and not a problem with MadExcept? I came to that thought since sometimes when exceptions happen while in debugging sessions, the debugger is also missing the most imporant line in the callstack - very similar to the here-posted problem.

While looking at the up-most lines: There are some lines (e.g. the CriticalSection parts) that (from my understanding) should not be in this trace as they happend right before the incident but not in explicitly this call stack. By the way, for my understanding, which lines of a call stack are most reliable? The top-most, bottom-most? Inbetween? Is there a way to tell that? (Naturelly, I'd guess top-most.)

Code: Select all
operating system   : Windows 7 Tablet PC Service Pack 1 build 7601
system language    : English
system up time     : 1 day 6 hours
program up time    : 5 hours 35 minutes
processors         : 4x Intel(R) Core(TM) i7-2715QE CPU @ 2.10GHz
physical memory    : 1544/3423 MB (free/total)
free disk space    : (C:) 1,82 GB
display mode       : 1920x1080, 32 bit
process id         : $bdc
allocated memory   : 521,93 MB
largest free block : 546,75 MB
executable         : -------.exe
exec. date/time    : 2019-04-17 14:21
version            :
compiled with      : BCB 10.2 Tokyo
madExcept version  : 4.0.19
callstack crc      : $fa020679, $6a9bbf45, $89d50195
exception number   : 1
exception class    : EAccessViolation
exception message  : Zugriffsverletzung bei Adresse 00DC4271 in Modul '-------.exe'. Lesen von Adresse 6B736970.

main thread ($15b8):
00dc9797 +077 -------.exe memory                  91  +13 std._Uninit_copy
012888d9 +049 -------.exe Logging.cpp           2551   +5 Logging.DoLogEntry
0058c1bc +00c -------.exe UtilRawStrings.h       549   +1 TEMPLATE_STRING.$bsubs$qi
0058c331 +009 -------.exe UtilRawStrings.h       447   +0 CLASS_STRING.operator const char *
012b4370 +5b0 -------.exe UtilTime.cpp           248  +58 TTimeval.GetDateTimeStringIntern
0141fc56 +002 -------.exe System.SyncObjs       1065   +0 TCriticalSection.Leave
012a7ae5 +009 -------.exe UtilIpc.cpp             78   +0 Win_CriticalSection.Leave
006f0907 +00b -------.exe UtilIpc.h               84   +0 IPC_CriticalSection.Leave
01287ebb +2b3 -------.exe Logging.cpp           2309  +64 LogWrite.ThreadWrite
017cfd1d +05d -------.exe System                          AnsiStringBase.Create
0040ff64 +01c -------.exe dstring.h              493   +0 System.AnsiStringT
00415ee6 +016 -------.exe xmemory                         Utf8String.Create
0047409e +036 -------.exe xmemory                 28   +3 std._Construct
00473445 +009 -------.exe xmemory                144   +2 std.allocator
0141fc56 +002 -------.exe System.SyncObjs       1065   +0 TCriticalSection.Leave
012879c1 +2c1 -------.exe Logging.cpp           2137  +19 LogWrite.WriteExtended
012888d9 +049 -------.exe Logging.cpp           2551   +5 Logging.DoLogEntry
Something must be missing here!
00b74367 +02f -------.exe SimpleJobhandler.cpp   369   +2 jhm.TSimpleJobhandler.DiscardJob
00b72e23 +82b -------.exe SimpleJobhandler.cpp   279  +53 jhm.TSimpleJobhandler.JobhandlerLoopBody
00d634bd +b89 -------.exe SpsConnectModule.cpp   706 +163 nx.TSpsConnectMod.OnTelegramm
012888d9 +049 -------.exe Logging.cpp           2551   +5 Logging.DoLogEntry
017becbf +00c -------.exe                                 memset
01544b34 +054 -------.exe Vcl                             Themes.TStyleManager.HandleMessage
00b43c70 +020 -------.exe Jobhandler.cpp        1032   +4 jhm.TJobhandlerBase.JobhandlerLoop
012b6ebd +08d -------.exe UtilTime.cpp          1396   +9 TTimeEventWrapper.OnVclTimer
0151af37 +00f -------.exe Vcl.ExtCtrls          3120   +1 TTimer.Timer
0151ae1b +02b -------.exe Vcl.ExtCtrls          3078   +4 TTimer.WndProc
013b42ac +014 -------.exe System.Classes       17405   +8 StdWndProc
7584cc3b +00a USER32.dll                                   DispatchMessageW
0158faf3 +0f3 -------.exe Vcl.Forms            10641  +23 TApplication.ProcessMessage
0158fb36 +00a -------.exe Vcl.Forms            10671   +1 TApplication.HandleMessage
0158fe6d +0c9 -------.exe Vcl.Forms            10809  +26 TApplication.Run
00404476 +08a -------.exe -------.cpp            34   +6 wWinMain
017bdbfc +014 -------.exe                                 __internal_malloc
017cb3fd +12d -------.exe                                 __wstartup
759fef1a +010 kernel32.dll                                 BaseThreadInitThunk