D10 Seattle 32-bit exe hangs with madExcept, 64 does not

[obl918]

Installed the new madExcept in D10 Seattle. I ended up having the same problem I did when I originally built the packages myself. At that time I assumed there might have been a change necessary for D10 Seattle so I just waited...

Anyway, my 64-bit exe works fine. My test exception is handled as expected, etc.

The same project, when built with 32-bit, hangs on startup. The main form is never initialized and something causes a CPU core to peg as nothing happens. Here is the trace report from madTraceProcess32. Any ideas?

Code: Select all

date/time          : 2015-09-10, 07:51:44, 244ms
computer name      : CHIANA
user name          : Brandon
registered owner   : Windows User
operating system   : Windows 10 x64 build 10240
system language    : English
system up time     : 2 days 16 hours
program up time    : 1 minute 39 seconds
processors         : 8x Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
physical memory    : 26420/32734 MB (free/total)
free disk space    : (C:) 75.11 GB
display mode       : 1920x1200, 32 bit
process id         : $176c
allocated memory   : 12.28 MB
largest free block : 1.20 GB
executable         : SwordSearcher8.x86.exe
exec. date/time    : 2015-09-10 07:50
version            : 8.0.0.8
compiled with      : Delphi 10 Seattle
madExcept version  : 4.0.12
callstack crc      : $6eaa1abb, $fc0cab5b, $fc0cab5b

main thread ($4cd4):
74d93069 +019 KERNELBASE.dll                                    VirtualQuery
0045a18c +0a0 SwordSearcher8.x86.exe System.SysUtils 22160  +13 CreateAVObject
0045a369 +065 SwordSearcher8.x86.exe System.SysUtils 22175   +5 GetExceptionObject
00409b9b +033 SwordSearcher8.x86.exe System          19208  +13 @HandleAnyException
775cae6a +00a ntdll.dll                                         KiUserExceptionDispatcher
0064002e +00a SwordSearcher8.x86.exe Vcl.Dialogs      5316   +3 TTaskDialogBaseButtonItem.SetEnabled
775c8e1a +00a ntdll.dll                                         NtQueryVirtualMemory
74d93069 +019 KERNELBASE.dll                                    VirtualQuery
004284a4 +110 SwordSearcher8.x86.exe madDisAsm        3514  +32 TryRead
00422fc5 +14d SwordSearcher8.x86.exe madDisAsm        1565  +20 CheckTarget
00423790 +17c SwordSearcher8.x86.exe madDisAsm        1726  +66 ParseCode
00425895 +075 SwordSearcher8.x86.exe madDisAsm        2378   +1 ParseCode
004258b3 +00f SwordSearcher8.x86.exe madDisAsm        2388   +1 ParseCode
004aff5a +eda SwordSearcher8.x86.exe madExcept       19267 +622 Init
00cbe72f +0a3 SwordSearcher8.x86.exe madExcept       19530  +22 initialization
0040a2fe +042 SwordSearcher8.x86.exe System          22736  +18 InitUnits
0040a367 +03f SwordSearcher8.x86.exe System          22808  +14 @StartExe
004109ae +042 SwordSearcher8.x86.exe SysInit          1217  +11 @InitExe
00cc58ff +017 SwordSearcher8.x86.exe SwordSearcher8    222   +0 initialization
74a23742 +022 KERNEL32.DLL                                      BaseThreadInitThunk

thread $378c:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

thread $49c8:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

thread $4960:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

thread $4974:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

thread $2c64:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

thread $8a8:
74a23742 +22 KERNEL32.DLL  BaseThreadInitThunk

[madshi]

That is very strange! Does the same problem happen inside and outside of the IDE?

Does this happen in all your projects or just in one? Can you reproduce it in a simple one button test project?

[obl918]

Inside and outside of the IDE, yes. I have only tested this in one project. I will see what I can do to reduce the problem to small project you can test. I was really hoping you would look at the stack trace and say "oh I know what that could be..."

[madshi]

I totally don't. I've zero ideas why VirtualQuery would get stuck.

That said, I *did* change something in that area, but simply reverting the change is not a good option because the change brings a significant performance improvement in certain situations. This problem is very probably related to that change. But I still don't understand why the problem occurs. And because of that I don't know how to fix it.

If you can't reproduce the problem in anything but your main project, one option we could look at would be to do a TeamViewer session, so I could look at the problem directly on your PC. It would be much easier, though, if you could reproduce the problem in a simple test project. Ideally in one that produces the same problem on my PC, too.

[obl918]

If I step through it in the IDE I get what seems to be an infinitely recurring exception over and over in madDisAsm line 1681 where it is assigning opcode := byte(code^). It throws an AV but keeps coming back to it.

The stack trace in the IDE goes from System.initunits to madExcept.MadExcept, MadExcept.Init, and then madDisAsm.Parsecode, where it keeps going over and over with an AV.

I know this isn't a test application but I need to get some time to see about narrowing it down.

[madshi]

Hmmm... I just now noticed that we're talking about madExcept initialization! Ok, now I think this is probably not caused by the change I made.

Is it possible that you have an old/outdated map or tds file flying around for your exe somewhere? It almost seems to me that madExcept thinks that SysUtils.InitUnits is not where it really is. Which would only make sense if there was a wrong map/tds file. Can you try deleting all map/tds files on your harddisk like "SwordSearcher*.map/*.tds"?

Still, it would be VERY important for you to try a brand new test project. Should not cost you more than 2 minutes to test!

[obl918]

Still, it would be VERY important for you to try a brand new test project. Should not cost you more than 2 minutes to test!

Oh yes, that was nothing. A new project works fine. It's the existing project that fails to work.

Deleting the map files and rebuilding did not change anything. (I got this problem also when I manually patched the exe specifying the map file I know is right.)

I will do some more research and see what I can change.

[madshi]

It seems very strange to me. But as I said, if all else fails, let's do a TeamViewer session.

[obl918]

I solved it by removing madExcept\Sources from my search path. Guess there was some kind of conflict between that and the precompiled .dcus? Anyway it's working now.

[madshi]

Can't really explain what happened there. But I'm glad you got it solved! I was already worrying that I might have officially released an unstable build! So I'm relieved...