Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Roman]

ok...I've replaced AfxBeginThread with CreateThread calls...let's give it a try:

https://mamedev.emulab.it/clrmamepro/binaries/threadcmpro64.zip

[vicmarto]

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:

Code: [Select]

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

[Roman]

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

[Roman]

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

[vicmarto]

Thanks again Roman.

This is the new log:

Code: [Select]

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.

[Roman]

interesting....since it runs till the end. Have to check what some class destructors do then...

[vicmarto]

Hi Roman, did you take a look at those class destroyers? Thank you!

[Roman]

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....

[Roman]

https://mamedev.emulab.it/clrmamepro/binaries/exit2cmpro64.zip

very minor change...and I highly doubt it changes anything....but who knows ;-)

[vicmarto]

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! 

Now, if only the changes could be merged... 

Code: [Select]

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


[Roman]

so no crash I guess? Interesting ;-)

[vicmarto]

I spoke too soon, seems some engines don't crash and others crashes 

For me it's already as is. But, if you want to experiment more, I would be happy to help!

Code: [Select]

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


[Roman]

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?

[vicmarto]

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!! 

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), version 19.0.1, crashes

[Roman]

use Wine64 5.1 and 5,2 then ;-)

[vicmarto]

Yes, it's OK!! 

[Roman]

Did the old version (https://mamedev.emulab.it/clrmamepro/binaries/exitcmpro64.zip) crash in Wine64 5.1 and 5,2?

[vicmarto]

Eeeerrr, sorry for confusion: no, they are not crashing.

[Roman]

ok...so I can blame github.com/PhoenicisOrg/winecx ;-)

[vicmarto]

Yes, I was thinking the same