Call stack missing the most important line
Call stack missing the most important line
Hi,
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!
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
Can you reproduce this issue in a brand new (almost empty) test project?
Re: Call stack missing the most important line
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
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).
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
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
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?
--Iconic
--Iconic
Re: Call stack missing the most important line
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.)
(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 : 7.4.26.1
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