Furnace crashed while playing a certain song
brickblock369 opened this issue · 30 comments
I was playing this song, and it somehow crashed.
Sadly, furnace_crash.txt is not useful. If you are using an artifact from the Actions tab, please make sure you have extracted furnace.pdb alongside furnace.exe.
That is odd. I extracted both furnace.pdb and furnace.exe, considering that both of the "Date modified" is at the same time.
It is causing Furnace 0.6.7 and newer to freeze (Maybe some older, but 0.6.3 works). And, because it's just freezing, it's not throwing an error.
Update: It actually does load eventually on the Win64 build, but it crashes on both Win32 builds of 0.6.7. More weird stuff.
32-bit specific crash... Oh no...
I am unable to reproduce this bug. I have tried loading this song over and over for a while, yet none of these attempts have resulted in a crash.
It does take very long to load - megasamples and rendering don't go well together.
Valgrind does not detect any errors either...
@Supreme-Man-1942 May you provide a backtrace? Download the latest 32-bit artifact in Actions tab, extract everything including furnace.pdb and try crashing Furnace. Then look at furnace_crash.txt in your user directory (e.g. C:\Users\username).
Now I can only get it to crash in the WinXP build, and that might just be because I'm using Win10. I'm going to see if I can test it on XP.
Update: This is so weird. It suddenly started crashing Standard 32 again, but it won't crash on the XP build in my VM... And the latest artifact won't crash.
Update 2: It seem intermittent whether it'll crash or not, now WinXP build isn't crashing on Win10, but the Standard 32 is. So far, the latest artifact has never crashed.
Do you at least have furnace_crash.txt?
It isn't giving any useful info, that I know of, but here:
Stack trace (most recent call last):
#5 Object "", at 0x77b680ce, in RtlGetAppContainerNamedObjectPath
#4 Object "", at 0x76c6fcc9, in BaseThreadInitThunk
#3 Object "", at 0x6e12f0, in ??
#2 Object "", at 0x1135cd4, in ZNK9RtMidiOut10isPortOpenEv
#1 Object "", at 0x76c71025, in GetStartupInfoA
#0 Object "", at 0xfc1e80, in ZN9RtMidiOutC1EN6RtMidi3ApiERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Guess what. I tried opening a different song ("donttryreality.fur". You might recognize it.), and it crashed the same way... I'm wondering if 0.6.7 Win32 somehow failed to compile properly, or something, because they are the only ones I can get to crash like that. Here's the new furnace_crash.txt. It seems a little more useful, though...
Stack trace (most recent call last):
#5 Object "", at 0x77b680ce, in RtlGetAppContainerNamedObjectPath
#4 Object "", at 0x76c6fcc9, in BaseThreadInitThunk
#3 Object "", at 0xb412f0, in ILT+745(?empty?$vectorPAUDivWavetableV?$allocatorPAUDivWavetablestdstdQBE_NXZ)
#2 Source "D:\a\furnace\furnace\extern\fftw\rdft\scalar\r2cb\r2cb_128.c", line 2781, in r2cb_128 [0x1595cd4]
#1 Object "", at 0x76c71025, in GetStartupInfoA
#0 Source "D:\a\furnace\furnace\src\engine\platform\sound\sid2\filter.h", line 245, in Filter2::clock [0x1421e80]
Edit: I just figured out that it's being caused by dragging and dropping the file into the program. But it still only happens in 0.6.7 Win32. It also doesn't matter what kind of file it is. It can be a .exe and it'll crash.
Guess what. I tried opening a different song ("donttryreality.fur". You might recognize it.), and it crashed the same way... I'm wondering if 0.6.7 Win32 somehow failed to compile properly, or something, because they are the only ones I can get to crash like that. Here's the new furnace_crash.txt. It seems a little more useful, though...
Stack trace (most recent call last): #5 Object "", at 0x77b680ce, in RtlGetAppContainerNamedObjectPath #4 Object "", at 0x76c6fcc9, in BaseThreadInitThunk #3 Object "", at 0xb412f0, in ILT+745(?empty?$vectorPAUDivWavetableV?$allocatorPAUDivWavetablestdstdQBE_NXZ) #2 Source "D:\a\furnace\furnace\extern\fftw\rdft\scalar\r2cb\r2cb_128.c", line 2781, in r2cb_128 [0x1595cd4] #1 Object "", at 0x76c71025, in GetStartupInfoA #0 Source "D:\a\furnace\furnace\src\engine\platform\sound\sid2\filter.h", line 245, in Filter2::clock [0x1421e80]
Edit: I just figured out that it's being caused by dragging and dropping the file into the program. But it still only happens in 0.6.7 Win32. It also doesn't matter what kind of file it is. It can be a .exe and it'll crash.
Version of Windows?
Windows 10 22H2.
Go to Event Viewer and find the latest application crash event related to Furnace. If you see something with the word "ill" or "illegal", then what is your processor?
It says "Unknown".
Unknown? Are you running Windows on a virtual machine or ancient processor?
Furnace requires at least a Pentium III to run.
So... I've tested the standard 32bit version on multiple Win10 computers, and it crashed. I tested in on Linux Mint 32bit (Don't remember what version) through wine, and it didn't crash, I couldn't get it to open on Windows Vista 32, and it didn't crash on Windows XP. I have no idea what the bug is, but I'm wondering if it fixed itself, because I can only replicate it with both Win32 builds of 0.6.7, and it doesn't always crash in the XP one.
What do the crash logs say?
Stack trace (most recent call last):
#5 Object "", at 0x77b680ce, in RtlGetAppContainerNamedObjectPath
#4 Object "", at 0x76c6fcc9, in BaseThreadInitThunk
#3 Object "", at 0xba12f0, in ILT+745(?empty?$vectorPAUDivWavetableV?$allocatorPAUDivWavetablestdstdQBE_NXZ)
#2 Source "D:\a\furnace\furnace\extern\fftw\rdft\scalar\r2cb\r2cb_128.c", line 2781, in r2cb_128 [0x15f5cd4]
#1 Object "", at 0x76c71025, in GetStartupInfoA
#0 Source "D:\a\furnace\furnace\src\engine\platform\sound\sid2\filter.h", line 245, in Filter2::clock [0x1481e80]
Two things are puzzling me about this:
1: None of the files I'm dragging in use sid2.
2: The file it's pointing to has never changed, and yet it doesn't crash on other builds.
I'm honestly thinking maybe someone should try recompiling 0.6.7 Win32, and see if it still crashes.
You'll never guess what just happened... Furnace 0.6.8pre2-win32 normal and XP-only just crashed when I drag and dropped a file into them (I'm using Windows 10)...
Stack trace (most recent call last):
#14 Object "", at 0x77b680ce, in RtlGetAppContainerNamedObjectPath
#13 Object "", at 0x76c6fcc9, in BaseThreadInitThunk
#12 Object "", at 0x7512f0, in ??
#11 Object "", at 0x11f5a34, in ZNK9RtMidiOut10isPortOpenEv
#10 Object "", at 0x76c71025, in GetStartupInfoA
#9 Object "", at 0x107f360, in ZN9RtMidiOutC1EN6RtMidi3ApiERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
#8 Object "", at 0xae2fac, in ??
#7 Object "", at 0xf8f0eb, in ZN9RtMidiOutC1EN6RtMidi3ApiERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
#6 Object "", at 0xf8e825, in ZN9RtMidiOutC1EN6RtMidi3ApiERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
#5 Object "", at 0x8a3ce2, in ??
#4 Object "", at 0x77b43d66, in RtlFreeHeap
#3 Object "", at 0x77b8806d, in RtlGetNtGlobalFlags
#2 Object "", at 0x11c77d0, in ZNK9RtMidiOut10isPortOpenEv
#1 Object "", at 0x18d56a4, in ZTI11RtMidiError
#0 Object "", at 0x11f5a62, in ZNK9RtMidiOut10isPortOpenEv
Any file? o-o
Sadly, I am unable to boot up Windows at the moment, so the only way we can make progress is with a debugger........
So. I tested it on a Windows XP 32 computer, and it didn't crash. I tested it on a Windows Vista 32 computer, and the XP-only version didn't crash, but I couldn't get the standard 32 bit version to run, for some reason. Also, the standard 32 bit version isn't crashing on Windows 10 now, but the XP-only one is. I also noticed that it's crashing before even attempting to load the file, because if I drag-and-drop any file (Furnace module or not) into the program when another unsaved project is loaded, it crashes before asking if I want to save the project.
Highly possible it got fixed with 1bc87a1
@Supreme-Man-1942 test now
Nope - this is a crash with a backtrace.
Why are you using the XP version? The standard builds are fine!
Shouldn't bugs get fixed
Not sure if this is related, but the normal 0.6.8 build freezes for around 7 seconds.
The file is fairly big, 6.5mb, so loading will take a while
I know for a fact that large samples can be overwhelmingly big so in my latest song I had to cut 95% of the only sample.
So, I can't confirm that it's been fixed because it's so inconsistent, but so far I haven't been able to recreate it with the latest versions of furnace.
Could have been related to a file picker hang reported weeks ago. Closing as done for now.