Erengy, this one is really tricky.
I was using your version from #36 for a while and I noticed that every time my laptop wakes up from hibernation, Taiga crashes. After a lot of trials I finally managed to reproduce it persistently with following scenario:
- Open Taiga
- Have Samba folder opened up in the background (yes, really)
- Hibernate the computer
- Turn the computer on
- Taiga crashes, while Explorer shows that Samba folder can't be accessed (because Windows haven't managed to connect to wifi yet).
Taiga has stopped working
Problem Event Name: APPCRASH
Application Name: Taiga.exe
Application Version: 1.1.8.0
Application Timestamp: 5414eac6
Fault Module Name: Taiga.exe
Fault Module Version: 1.1.8.0
Fault Module Timestamp: 5414eac6
Exception Code: c0000005
Exception Offset: 000d0bae
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1045
Additional Information 1: f400
Additional Information 2: f40040f5ee2cf5c16aefa5fccaa073c7
Additional Information 3: bc6f
Additional Information 4: bc6fa234b2f89940e9d54ff92ae9361d
Anyway, I tried to get some more intel for you...
- I compiled
HEAD
and confirmed the error is still there.
- I tried to reproduce it on my PC where I have VS installed so I could debug it, but:
- I can't hibernate it,
- after putting PC to sleep and resuming, Taiga... just wasn't there. It's better than crash, I think?
- I don't have VS on the laptop, so I couldn't debug it that way.
- I figured I could debug it remotely, and I actually managed to do that. I attached debugger to Taiga just after executing such scenario, while still having "Taiga has stopped working" screen. Only two threads were active, the first one being
App::MessageLoop
stuck at executing GetMessage()
(this one looks innocent to me), and the other one being FolderMonitor::ThreadProc
stuck at CopyMemory(file_name, pfni->FileName, pfni->FileNameLength);
.
Hovering pfni->FileNameLength
shows very interesting value: 3452816845 (it's almost 3.2GB). Turns out the whole folder_info->buffer_
variable is filled with rubbish (at least 500 bytes equal to \205
).
Well, that's as far as my analysis goes - from what I can tell, these get filled with calls to WinAPI like this one. I have no idea why it fills it with such things. 😨
Edit: perhaps it doesn't fill it at all, and that stuff just... was there already? As far as I can tell, return values of these calls are left unchecked. That might be reason behind this behavior.