| |
Grue
Registered: Dec 2001
Posts: 162 |
VICE binary builds crashing randomly
I have had a problem with Modern Vice builds crashing randomly on my computer for years.
I finally decided to build Vice for Windows myself with debugging enabled to see what was happening. To my surprise, Vice no longer crashes with—-enable-debug-gtk3ui —-enable-debug enabled.
Then I tried to build Vice without debug switches, and it crashed like before.
I don't know why it behaved like this on my computer. I know it works okay for some, but it would be nice if it got fixed so I don't have to use a debug build for my development needs.
I do have 5 game controllers connected, which is not common, I can imagine. I also currently have 4 displays active. Maybe this is why?
And no, I'm still unable to get the sf.net account working, so I won't open a ticket about it. |
|
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Memory differences between debug and release. Usually initialising variables or accessing freed memory.
Have you tried enabling CRT debug heap checking? |
| |
Grue
Registered: Dec 2001
Posts: 162 |
I don't understand what that means, and frankly, I'm not interested in investing more time in this than I have to. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Quote:I'm not interested in investing more time in this
That's the main problem here
Someone who is using windows, and is interested in fixing this, needs to step up. |
| |
Stone
Registered: Oct 2006
Posts: 172 |
I'm a Windows user and I would be willing to give it a go provided there was some likelyhood that I could reproduce the problem or had some idea in what part of the code the problem was.
>I do have 5 game controllers connected, which is not common, I can imagine. I also currently have 4 displays active. Maybe this is why?
Have you tried different permutations of this setup?
Can you run it under a debugger and produce backtraces in some form, of the running threads? |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: I don't understand what that means, and frankly, I'm not interested in investing more time in this than I have to.
If you're using MSVC to compile, it can catch memory block issues quickly, often showing what block has a problem and where it was allocated/freed/accessed.
Look for: _CRTDBG_CHECK_ALWAYS_DF
https://learn.microsoft.com/en-us/cpp/c-runtime-library/referen.. |
| |
Grue
Registered: Dec 2001
Posts: 162 |
I'm sorry but I dont have an idea what causes this, its been bugging on me for years. Naturally I have been iterating on this, it works on on my laptop but on this desktop. Thats all I can say for sure.
Currently build with msys2 takes an hour, ~25mins for the configure script to finish and rest of the time for the actual build.
I don't have enough patience to work on that kind of process.
I don't know anything about coding on modern computers or using other debuggers than retrodebugger which also crashes randomly on my computer as it uses old build of vice for the commodore 64 magic.
I got kicked out of #vice-dev some time ago so, I guess someone with access to sf.net can help you :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
There is no MSVC involved here, we dropped that ages ago |
| |
Martin Piper
Registered: Nov 2007
Posts: 726 |
Quote: I'm sorry but I dont have an idea what causes this, its been bugging on me for years. Naturally I have been iterating on this, it works on on my laptop but on this desktop. Thats all I can say for sure.
Currently build with msys2 takes an hour, ~25mins for the configure script to finish and rest of the time for the actual build.
I don't have enough patience to work on that kind of process.
I don't know anything about coding on modern computers or using other debuggers than retrodebugger which also crashes randomly on my computer as it uses old build of vice for the commodore 64 magic.
I got kicked out of #vice-dev some time ago so, I guess someone with access to sf.net can help you :)
When I build Vice or its associated tools, I tend to convert the build to MSVC. It doesn't take long to do that, it uses a much better compiler, and it adds a whole bunch of debugging support which helps find problems exactly like this. To be honest the Vice team did a very wrong decision when moving to another compiler on Windows. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
MSVC being a better C compiler is a funny idea :) I very much doubt any recent version of the source still builds with MSVC either - since we removed all the MSVC specific hacks/ifdefs that were needed to make this possible (because of the superior compiler) many years ago.
In any case, this babble doesn't help. Whoever steps up to look at this surely doesn't need someone to tell him how to debug. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
First and for all we need Grue to remove the 5 controllers and use just 1 display - to check if that is of any cause or not.
just that desktop, plain mouse, keyboard, 1 display and run vice. still wrecking? yes/no.
I have seen proprietary c/cpp compilers even creating "working" release builds that should not even start :-D
once an apprentice in our company had a task from school: build a tic-tac-toe printing to the console. it worked with the companies bought famous compiler - but he had to use gcc - it was not even starting. 5 colleagues standing around not understanding why - cursing gcc :-D
when I saw the little crowd I asked them what's the matter. They showed me. I showed them the missing memory initialisation, still puzzled to this day how that expensive bs-compiler could generate a running program for that.
and it was NOT MSVC :-D the apprentice fixed it and it worked correctly on gcc. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
Quote: First and for all we need Grue to remove the 5 controllers and use just 1 display - to check if that is of any cause or not.
just that desktop, plain mouse, keyboard, 1 display and run vice. still wrecking? yes/no.
I have seen proprietary c/cpp compilers even creating "working" release builds that should not even start :-D
once an apprentice in our company had a task from school: build a tic-tac-toe printing to the console. it worked with the companies bought famous compiler - but he had to use gcc - it was not even starting. 5 colleagues standing around not understanding why - cursing gcc :-D
when I saw the little crowd I asked them what's the matter. They showed me. I showed them the missing memory initialisation, still puzzled to this day how that expensive bs-compiler could generate a running program for that.
and it was NOT MSVC :-D the apprentice fixed it and it worked correctly on gcc.
And NO, not blaming the vice-team for grues problems with that post :-D it was about proprietary compilers and how they can suck. |
| |
Grue
Registered: Dec 2001
Posts: 162 |
Quoting DanzigFirst and for all we need Grue to remove the 5 controllers and use just 1 display - to check if that is of any cause or not.
just that desktop, plain mouse, keyboard, 1 display and run vice. still wrecking? yes/no.
If it would be that simple, this report would have been quite different. As I said, this has been bugging me for years and I have tried everything I can think of, and, I can think alot, some say too much ;) |
| |
Grue
Registered: Dec 2001
Posts: 162 |
I just remembered that I saw -o3 as cflags on build, I cannot remember if there was any other optimizations defined.
~20 years ago when I was a enthuastic gentoo linux user, I remember that using too much compiler optimization wasn't too good idea in the long run.
I guess I can try that much, I mean to compile it without --debugs using -o2 and see what happens.
Compilers have come a long way in 20 years I'm sure, but... |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
https://learn.microsoft.com/en-us/windows/win32/wer/collecting-.. may allow you to create a crash dump then someone else can alayse |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
I'm pretty sure this is a race condition somewhere, which is why none of "us" can reproduce it (with our crap PCs =P). Burglar had weird crashes on his monster machine as well in the past - on Linux even.
However if no one steps up to have a look, nor people are willing to spend time on testing - or even properly report bugs... oh well |
| |
Grue
Registered: Dec 2001
Posts: 162 |
Quote: I'm pretty sure this is a race condition somewhere, which is why none of "us" can reproduce it (with our crap PCs =P). Burglar had weird crashes on his monster machine as well in the past - on Linux even.
However if no one steps up to have a look, nor people are willing to spend time on testing - or even properly report bugs... oh well
35min+ has passed running on GDB, and it hasn't even managed to open the main window yet.
with tools like msys2 this is pointless. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
Well, process creation and dynamic linking in Windows is hilariously slow - that's the main problem here. (It's also why configure takes forever in msys)
I'd try if the problem exists in the SDL build as well first - since that should start up much faster (because it doesn't link to god knows what) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11390 |
i somehow managed to produce this:
(x64sc.exe:9972): GLib-GIO-ERROR **: 23:00:25.168: No GSettings schemas are installed on the sys
tem
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffe53a0b80b in ?? () from /mingw64/bin/libglib-2.0-0.dll
(gdb) bt
#0 0x00007ffe53a0b80b in ?? () from /mingw64/bin/libglib-2.0-0.dll
#1 0x00007ffe53a0b8e7 in ?? () from /mingw64/bin/libglib-2.0-0.dll
#2 0x00007ffe53a0bc81 in ?? () from /mingw64/bin/libglib-2.0-0.dll
#3 0x00007ffe53a0c048 in ?? () from /mingw64/bin/libglib-2.0-0.dll
#4 0x00007ffe538c0fff in ?? () from /mingw64/bin/libgio-2.0-0.dll
#5 0x00007ffe5864ce0c in ?? () from /mingw64/bin/libgobject-2.0-0.dll
#6 0x00007ffe5864e8d5 in ?? () from /mingw64/bin/libgobject-2.0-0.dll
#7 0x00007ffe58650d5b in ?? () from /mingw64/bin/libgobject-2.0-0.dll
#8 0x00007ffe58651084 in ?? () from /mingw64/bin/libgobject-2.0-0.dll
#9 0x00007ff62e360cf2 in ui_init ()
at C:/Users/groepaz/Desktop/c64/vice/trunk/vice/src/arch/gtk3/ui.c:2174
#10 0x00007ff62e15f306 in main_program (argc=<optimized out>, argc@entry=3,
argv=argv@entry=0x622440) at C:/Users/groepaz/Desktop/c64/vice/trunk/vice/src/main.c:409
#11 0x00007ff62e408a04 in main (argc=3, argv=0x622440)
at C:/Users/groepaz/Desktop/c64/vice/trunk/vice/src/arch/gtk3/gtk3main.c:70
This is after building and running directly from the tree like this:
gdb -args ./src/x64sc -directory ./data
It works fine when i start without gdb though, so this may or may not be the problem you are seeing |
