| |
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. |
|
... 10 posts hidden. Click here to view all posts....
|
| |
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: 11391 |
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: 11391 |
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: 11391 |
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 |
