| |
Grue
Registered: Dec 2001
Posts: 161 |
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. |
|
... 8 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
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: 161 |
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: 161 |
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: 11377 |
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: 161 |
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: 11377 |
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: 11377 |
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 |
| Previous - 1 | 2 - Next |
