EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: vicmarto on 03 February 2020, 11:01
-
Hello!
Clrmamepro 64 bits (v. 4.036a) crash when runs under wine64 (v. 5.0).
The Welcome screen appears correctly, and after pressing the accept button, it crash.
Attachment is the log report:
-
Same happens under wine64 (v. 4.21). This is the report:
Unhandled exception: page fault on read access to 0x00000020 in 64-bit code (0x000000014045019a).
Register dump:
rip:000000014045019a rsp:0000000001b6fd60 rbp:0000000001b6ffd0 eflags:00010246 ( R- -- I Z- -P- )
rax:0000000000000000 rbx:0000000000000001 rcx:0000000000000000 rdx:0000000000fd38f0
rsi:000000007be7bdcc rdi:0000000000000003 r8:00000001405df970 r9:0000000001b6fd20 r10:000047af2a80da37
r11:0000000000000000 r12:0000000000000000 r13:0000000000000000 r14:0000000000fd6fc0 r15:0000000000000000
Stack dump:
0x0000000001b6fd60: 0000000000000000 0000000000000000
0x0000000001b6fd70: 0000000000000005 0000000000000005
0x0000000001b6fd80: 0000000000fd6fc0 000000014043cd62
0x0000000001b6fd90: 0000000000000000 000000007be7bdcc
0x0000000001b6fda0: 0000000000fd6fc0 0000000000000000
0x0000000001b6fdb0: 000000014043cd34 000000007bc93893
0x0000000001b6fdc0: 0000000000000000 0000000000000000
0x0000000001b6fdd0: 0000000000000000 0000000000000000
0x0000000001b6fde0: ffffffffffffffff 000000007bcb77d0
0x0000000001b6fdf0: 000000007bc40c50 0000000000000000
0x0000000001b6fe00: 0000000001b6fde0 000000014043cd34
0x0000000001b6fe10: 0000000001b6fdc0 0000000001b6ffd0
Backtrace:
=>0 0x000000014045019a in cmpro64 (+0x45019a) (0x0000000001b6ffd0)
1 0x000000014043cd62 in cmpro64 (+0x43cd61) (0x0000000001b6ffd0)
0x000000014045019a: movq 0x0000000000000020(%rax),%rcx
Modules:
Module Address Debug info Name (41 modules)
PE 220000- 235000 Deferred msimg32
PE 240000- 35c000 Deferred shlwapi
PE 360000- 3a7000 Deferred imm32
PE 3b0000- 75c000 Deferred oleaut32
PE 760000- 85b000 Deferred oleacc
PE 860000- a06000 Deferred wininet
PE b20000- b2d000 Deferred api-ms-win-core-fibers-l1-1-1
PE b30000- b3e000 Deferred api-ms-win-core-localization-l1-2-1
PE b40000- ccf000 Deferred setupapi
PE 10000000- 101a5000 Deferred 7z_64
PE 61340000- 6134d000 Deferred api-ms-win-core-localization-obsolete-l1-2-0
PE 62140000- 621c5000 Deferred uxtheme
PE 62600000- 626c9000 Deferred usp10
PE 637c0000- 6391b000 Deferred winmm
PE 64940000- 64982000 Deferred shcore
PE 65000000- 6550c000 Deferred ole32
PE 65680000- 6568e000 Deferred api-ms-win-core-sysinfo-l1-2-1
PE 65780000- 6579c000 Deferred version
PE 66440000- 6649b000 Deferred msacm32
PE 66600000- 6660d000 Deferred api-ms-win-core-datetime-l1-1-1
PE 66780000- 6678d000 Deferred api-ms-win-core-string-l1-1-0
PE 69f20000- 69f24000 Deferred advapi32
PE 69fc0000- 69fc4000 Deferred ws2_32
PE 6b010000- 6b0f8000 Deferred user32
PE 6b290000- 6b297000 Deferred gdi32
PE 6b430000- 6b434000 Deferred msvcrt
PE 6b520000- 6b52b000 Deferred winspool
PE 6b580000- 6b584000 Deferred ucrtbase
PE 6c010000- 6c8e6000 Deferred shell32
PE 6ca50000- 6ca56000 Deferred winemac
PE 6d9c0000- 6da10000 Deferred mpr
PE 6e340000- 6e34e000 Deferred api-ms-win-core-synch-l1-2-0
PE 6e6c0000- 6ea75000 Deferred comctl32
PE 6f480000- 6f6b7000 Deferred gdiplus
PE 6fbc0000- 6fdae000 Deferred rpcrt4
PE 71040000- 7129a000 Deferred kernelbase
PE 7b410000- 7b5cb000 Deferred kernel32
PE 7bc10000- 7bc14000 Deferred ntdll
ELF 7c400000- 7c405000 Deferred <wine-loader>
PE 140000000- 14081f000 Export cmpro64
PE 180000000- 180057000 Deferred unrar64
Threads:
process tid prio (all id:s are in hex)
0000000e services.exe
00000023 0
0000001a 0
00000015 0
00000014 0
00000013 0
00000010 0
0000000f 0
00000011 plugplay.exe
00000017 0
00000016 0
00000012 0
00000018 winedevice.exe
00000020 0
0000001d 0
0000001c 0
0000001b 0
00000019 0
0000001e explorer.exe
00000029 0
00000028 0
00000027 0
0000001f 0
00000021 winedevice.exe
00000026 0
00000025 0
00000024 0
00000022 0
0000002a (D) C:\Program Files\cmp4036a_64\cmpro64.exe
0000002f 0
0000002c 0 <==
0000002b 0
System information:
Wine build: wine-4.21
Platform: x86_64
Version: Windows 7
Host system: Darwin
Host version: 18.7.0
-
https://www.emulab.it/forum/index.php?topic=4434.msg17638#msg17638 (https://www.emulab.it/forum/index.php?topic=4434.msg17638#msg17638)
To sum it up: Yes it does (at least in a Mac environment).
Would be great if someone can retest it (with latest wine) on a Linux system....last time I've checked it it ran fine. The reported problem was Mac (Wine) only.
-
So I've installed an ubuntu-18.04.3-desktop-amd64 on a virutal machine,
Installed a wine 5.0 version on it, downloaded the 64bit version of clrmamepro and ran it with wine....no problems, no crashes...
so any information about what you are using?
-
So I've installed an ubuntu-18.04.3-desktop-amd64 on a virutal machine,
Installed a wine 5.0 version on it, downloaded the 64bit version of clrmamepro and ran it with wine....no problems, no crashes...
so any information about what you are using?
Thanks Roman for taking the time to do this. Seems the macOS implementation of wine64 is sensibly different than linux, because it's crashing.
Steps to reproduce it:
- Install Wineskin-Winery-1.8.4: https://github.com/Gcenx/WineskinServer/releases/latest
- Run it and Update the Wrapper to the last version (2.9.0.6) presing the [Update] button
- Next press the [＋] button to install the "SW9WineStaging64Bits 5.0" Engine
- Press the [Create New Blank Wrapper] button and name it, for example: cmpro64.app
- Close Wineskin-Winery and Run /Applications/Wineskin/cmpro64.app
- Press the [Install Software] Button
- And then [Move a Folder Inside], moving a clrmamepro install (previously unzipped)
- Exit pressing [Quit] and run one more time /Applications/Wineskin/cmpro64.app
- This time, clrmamepro opens. Press [OK] and it crashes
I expect this make sense...
If there is something I can do, I would love to help.
Thanks!
-
well...first of all I need to get an MacOS environment....... ;-)
But I guess in the meantime I may add some logging steps for a private build which might give a clue where it exits....
-
But I guess in the meantime I may add some logging steps for a private build which might give a clue where it exits....
Yeah, I would be happy to help.
-
https://mamedev.emulab.it/clrmamepro/binaries/cmpro64.zip
contains an exe which creates a cmpro.log in the cmpro folder....replace the exe, run it, send me the log ;-)
-
Thanks Roman for your interest :)
Here is the cmpro.log:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
And attached, the related backtrace.txt (this time using Wine64 5.1).
Hope helps!
-
interesting...it seems to quit within (or after) the 7z rename test (which runs an installed 7z instance to see if it already supports the rename command).
Will check it later at home
-
for a quick test you can open your cmpro.ini (hmm...if you actually have one if it crashes for you so early)
and add/update the setting:
Packer_7z_Exe_Ren = off
-
Thanks for your answer.
Did't have a cmpro.ini, so created one with this content, it's ok?:
[CMPRO SETTINGS]
Packer_7z_Exe_Ren = off
But, got same result:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
-
I will build a version with some more log details in that 7z rename part and one without that function.....
-
by the way, it could also be the rar rename test
Packer_Rar_Exe_Ren = off
https://mamedev.emulab.it/clrmamepro/binaries/morecmpro64.zip
-
by the way, it could also be the rar rename test
Packer_Rar_Exe_Ren = off
Yeah! This makes some progress! New log:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
parse engine
This was using the Tuesday cmpro64.exe, now I'm going to test the new build from today and report again!
-
Well, finally same log with "morecmpro64.zip".
The backtrace is attached.
-
what does the cmpro.log say if you enable the two options again ( = on)
....and it still crashes ???? (most likely after parse engine)
-
what does the cmpro.log say?
The same, for both versions:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
parse engine
-
what does the cmpro.log say?
With both on, this is the log:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
test 7z rename test remove
test 7z rename test compress
-
seems to be related to the last entry in this post:
https://github.com/Gcenx/WineskinServer/issues/22
It seems that the AfxBeginThread call seems to cause issues in that wineskin-whatever environment...and your last log entries are exactly both placed shortly before such a call is done....
So...I will check if this can be replaced with CreateThread in all cases (as described in the post)....and we then can check if this resolves the problems for mac/wineskin users..... (however AfxBeginThread is also used in the 3rd party zip library....)
-
ok...I've replaced AfxBeginThread with CreateThread calls...let's give it a try:
https://mamedev.emulab.it/clrmamepro/binaries/threadcmpro64.zip
-
ok...I've replaced AfxBeginThread with CreateThread calls...let's give it a try:
https://mamedev.emulab.it/clrmamepro/binaries/threadcmpro64.zip
Wow! Seems we are doing some big progress, finally Clrmamepro opens without crash!. Not only that, but everything seems to work correctly: load MAME dat, scanner and rebuilder (zip, 7z and rar). Very happy!
Here is the new log:
testing cache file version
delete cache
show welcome message / clean cache message
get Current Time
test button bitmaps
check window sizes
check for update
init 7z lib
test 7z rename
test 7z rename test remove
test 7z rename test compress
test 7z rename test remove
test rar rename test remove
test rar rename test compress
test rar rename test remove
parse engine
prepare main dialog
set bitmaps
build window
default profiler
run profiler
init profiler
running profiler
init profiler
running profiler
Just a little glitch, when clicking [X] to close the Clrmamepro window, it crashed, it's not important but I preferred to said it. Attached is the backtrace.txt.
ok...I've replaced AfxBeginThread with CreateThread calls...
Can this call change from AfxBeginThread to CreateThread be integrated into the normal clrmamepro?
(however AfxBeginThread is also used in the 3rd party zip library....)
This is to compress or to decompress? Like I said before, seems both compress and decompress are ok.
A big thanks,
vicmarto
-
I will check what's happening on "exit" ;)
I don't know yet if the change from AfxBeginThread to CreateThread will make it since there are warnings out there to prefer AfxBeginThread over CreateThread which is a bit low level C runtime.....but I will check it....The current test build lacks setting the priority of the threads by the way...it was just a quick check to see if this is really related to that function.
Also I have to check where exaclty AfxBeginThread is used in the 3rd party lib (only did a quick text search on the sources)....
Thanks for testing
-
let's first find the exit problem...
https://mamedev.emulab.it/clrmamepro/binaries/exitcmpro64.zip
removed old log entries, added new ones just for closing
-
Thanks again Roman.
This is the new log:
onclose
ondestroy
save settings
free global memfile
unload button
delete 7z
remove empty dirs
remove temp www
free global
save lists
save global
save profiler xml
free logger
And the backtrace is attached.
-
interesting....since it runs till the end. Have to check what some class destructors do then...
-
Hi Roman, did you take a look at those class destroyers? Thank you!
-
sorry to not coming back to you earlier....really busy with real life at the moment. Yes, I had a look...but don't see anything wrong in there. Actually after the free logger only one from my destructors is called and "of course it works on my system" ;-)
After that only internal general win32 api closing stuff is called.....
but I try to have a look at it again this week....
-
https://mamedev.emulab.it/clrmamepro/binaries/exit2cmpro64.zip
very minor change...and I highly doubt it changes anything....but who knows ;-)
-
https://mamedev.emulab.it/clrmamepro/binaries/exit2cmpro64.zip
very minor change...and I highly doubt it changes anything....but who knows ;-)
Roman: I don't know what you did, but you're a genius, really. I'm so happy, thank you a thousand times! ;D
Now, if only the changes could be merged... 8)
onclose
ondestroy
save settings
free global memfile
unload button
delete 7z
remove empty dirs
remove temp www
free global
save lists
save global
save profiler xml
free logger
-
so no crash I guess? Interesting ;-)
-
I spoke too soon, seems some engines don't crash and others crashes :o
For me it's already as is. But, if you want to experiment more, I would be happy to help!
onclose
ondestroy
save settings
free global memfile
unload button
delete 7z
remove empty dirs
remove temp www
free global
save lists
save global
save profiler xml
free logger
-
what do you mean exactly with "some engines don't crash", others crash?
what did you do? Does it crash if you only start and directly quit? Does it crash if you start, load a profile, quit? etc...
can you describe the steps from start to end when it crashes?
-
Only start and then quit is enough to crash it. These are all the steps. Only crash at exit, using the program is all ok!! :o
About "some engines crash, some don't": I'm talking about different wine versions, for example:
- Wine64 5.1 and 5,2 don't crash
- The modified wine by Codeweavers(https://github.com/PhoenicisOrg/winecx (https://github.com/PhoenicisOrg/winecx)), version 19.0.1, crashes
-
use Wine64 5.1 and 5,2 then ;-)
-
Yes, it's OK!! ;D
-
Did the old version (https://mamedev.emulab.it/clrmamepro/binaries/exitcmpro64.zip) crash in Wine64 5.1 and 5,2?
-
Eeeerrr, sorry for confusion: no, they are not crashing.
-
ok...so I can blame github.com/PhoenicisOrg/winecx ;-)
-
Yes, I was thinking the same ;D
-
ok, updated setting the thread prio, new nightly available