Page 1 of 1

stack not accessible

Posted: Mon Feb 19, 2018 9:32 pm
by Jeff Cook
Hi
I'm getting this "stack not accessible" in a bug report .

Without the stack I'm a bit stuck as to finding out where the error is occuring. Unfortunately, I can't add debugging code as this happens intermittently and it is at a remote users site.

Any suggestions on how to proceed? I'm using Delphi XE and madExcept 4.0.11.

Below is the beginning of the bug report.

Cheers

Jeff
===============================================
date/time : 2018-02-15, 08:43:33, 939ms
computer name : OEM-PC
user name : OEM
operating system : Windows 8 x64 build 9200
system language : English
system up time : 1 hour 58 minutes
program up time : 6 seconds
processors : 8x Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
physical memory : 5164/8071 MB (free/total)
free disk space : (C:) 41.50 GB (E:) 563.16 GB
display mode : 1280x800, 32 bit
process id : $14e8
allocated memory : 70.31 MB
largest free block : 1.09 GB
command line : "E:\ASPECT\PropMan\apm v4.10.14.10.exe" -r ra
executable : apm v4.10.14.10.exe
exec. date/time : 2017-10-11 07:49
version : 4.10.14.10
compiled with : Delphi XE
madExcept version : 4.0.11
callstack crc : $90e5acee, $0287b302, $0287b302
exception number : 1
exception class : EAccessViolation
exception message : Access violation at address 0083C18A in module 'apm v4.10.14.10.exe'. Read of address 0000001C.

thread $25c0:
>> stack not accessible, exception location:
0083c18a +6 apm v4.10.14.10.exe edbcomps +0 TEDBSession.SetConnected

thread $2834: <priority:1>
.
.
.

Re: stack not accessible

Posted: Tue Feb 27, 2018 4:20 pm
by madshi
This crash report suggests that the process was in a really troublesome situation. This could be caused by a buffer overrun, by freeing a buffer twice, or by similarly bad things.

One thing you could try is activating the "instantly crash on buffer overrun" feature on the first page of the madExcept settings page. This feature will not fix the issue, but it may result in your program crashing at a more helpful location, producing a more useful crash report. You can check if you can reproduce any problems with this option enabled on your development PC or your test environments. If that doesn't help, you can also let the end user run the tests for you. In that case you'll have to distribute the madExcept32.dll with your EXE file (same folder), because the "instantly crash" feature won't work without the madExcept32.dll.

I should add that the "instantly crash" feature consumes a LOT of extra RAM, so there's a certain danger that your process might run out of RAM. But it might still be worth a try.

Re: stack not accessible

Posted: Wed Feb 28, 2018 9:25 pm
by Jeff Cook
Hi Madshi, thanks for your reply.

Will I be able to change these settings at runtime?

I'll be unable to test this in my development environment beyond checking the program runs.

The error I'm encountering only affects one user and doesn't occur in the development environment. I'm hoping to use a runtime parameter which I can set for that user only.

Cheers

Jeff

Re: stack not accessible

Posted: Wed Feb 28, 2018 9:27 pm
by madshi
Overrun is by far the most common issue, so choose that.

You can switch the "instantly crash" feature on/off simply by distributing or not distributing the madExcept32.dll with your EXE file. If you have the option enabled and the DLL is missing, the feature will simply be silently disabled.

Re: stack not accessible

Posted: Wed Feb 28, 2018 10:19 pm
by Jeff Cook
Hi again

I found the setting, but when I say:-

MESettings.CrashOnOverrun := bCrash; // where bCrash is a Boolean

I get a compiler error:-

[DCC Error] apmData.pas(6566): E2064 Left side cannot be assigned to

Hmm...

Re: stack not accessible

Posted: Wed Feb 28, 2018 10:24 pm
by madshi
You can't change this at runtime.

Re: stack not accessible

Posted: Thu Mar 01, 2018 3:59 am
by Jeff Cook
Bother!

I can work around that though.

Thanks for the help