| Index > Scribe > InScribe v2.1.30 crashes when receiving mail | |
|---|---|
| Author/Date | InScribe v2.1.30 crashes when receiving mail |
| Scott 05/12/2016 11:07am | I've got some email on my mail server that causes InScribe v2.1.30 and earlier versions, back to v2.1.19, to crash during the receive operation.
There is no crash dump produced. It crashes even if I select an empty folder, verifying that it is the reception and not the display portion of the code. |
| fret 05/12/2016 2:08pm | if I select an empty folder By this I assume you have an IMAP connection running? Might be worth finding the log for that connection and see what command it was up too. Turn logging on in the "Other" tab of the options. IMAP logs are in ~\AppData\Roaming\Scribe\ImapCache. Are there more than one accounts connected at the same time? (might worth isolating the exact one) Is it a common mail server host? (Microsoft/Gmail/large ISP etc?) Without a crash dump it's going to be very difficult to isolate the problem without access to the server/data in question. If it's not an account that is particularly private and you can change the password afterwards I'm happy to have a go at connecting to it from my end to reproduce the issue in a developer/debug environment. Alternatively I think the lack of crash dump might be caused by other software installing different versions of DbgHelp.dll that cause the crash dump to fail. At least that is my working theory at this point. If you have time and inclination, run a system wide search for files by that name and see which ones are in the path, and what versions / sizes they are. Maybe that could help isolate why crash dumps don't work for you and do for me and others. I'm also interested in whether some types of errors cause a normal crash dump, and others don't. You can force Scribe to crash to test the dump file creation by clicking the menu Tools -> Debug -> Crash. (Weird command to have but I use it to test the dump functionality from time to time). |
| Scott 07/12/2016 12:11pm | Would a call stack dump help?
> msvcr90.dll!6bd41661() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for msvcr90.dll] [External Code] Lgi9x32nop.dll!00960e30() Unknown [External Code] Scribe.exe!00702d32() Unknown Lgi9x32nop.dll!009a34ec() Unknown Scribe.exe!005f4cd9() Unknown Scribe.exe!005f01c0() Unknown Scribe.exe!00713f53() Unknown Scribe.exe!0040479e() Unknown Scribe.exe!006b5174() Unknown Scribe.exe!0069576b() Unknown Scribe.exe!006e290c() Unknown [External Code] Lgi9x32nop.dll!00aeabc5() Unknown [External Code] Lgi9x32nop.dll!00ae602d() Unknown Scribe.exe!006facd2() Unknown Scribe.exe!007113c6() Unknown Scribe.exe!00679de0() Unknown Scribe.exe!0050ebb1() Unknown [External Code] |
| fret 08/12/2016 7:32am | Would a call stack dump help? Somewhat... I'm just having a look at this stack trace now and a lot of the addresses don't match any symbols in v2.1.30. A few matched, in the code that saves an email to the Mail3 back end. Which if correct, leads me to believe you had either a POP3 receive active which was saving new mail to a mail3 folder -OR- you had an IMAP connection with new mail being filtering from the IMAP folder to a mail3 folder. So if there is any more context that you can give me that'd be good. |
| Scott 08/12/2016 11:08pm | I am receiving POP3 into a mail3 folder.
I tried to connect using IMAP to see if that would work better, but I got the following error: Error: Unknown OAUTH2 server 'imap.bell.net' (ask fret@memecode.com to fix) |
| Scott 09/12/2016 10:35am | The last few lines in the connection log are (slightly tweaked so they display):
</style> <-/head> <--~-|**|PrettyHtmlEnd|**|-~--> <-/html> <-- end group email --> --9nlWnTS9ocNmxdhsK3FKVLWiM6a5jwOaA8HvrLV-- |
| Scott 10/12/2016 11:09pm | I've picked off the offending email.
If I move this email out of the inbox on the mail server, Scribe is able to download without issue. I have sent this email to you. The Preview mail feature came in handy to narrow down the mail allowing me to download individual mail. I just needed to look in the trash for the first duplicated message. The preceding message was never received and crashed when individually selected. |
| fret 11/12/2016 6:23am | Thanks so much for doing the detective work. I've confirmed that causes the client to crash at my end too, so it's an easy fix now. I will get it sorted out in the next few days and make a release. The CSS library asserted just before the crash in the debug build, so I suspect it is the HTML display code. |
| fret 11/12/2016 1:56pm | There are 3 separate issues in that email:
1) The "to" address doesn't get parsed properly. Leaving a bunch of addresses in the one field. Causing: 2) A buffer to run out of space. Even though I'm using the "safe" string formatting functions unless you set an exception handler the software quits with an exception. I.e. it's designed to fail poorly by default. This is essentially a very bad design on the part of Microsoft's CRT library. What should happen and the whole point of the string formatting functions is that the should detect an out of buffer condition and NOT cause a crash, but return an error code. So I've added an exception handler that just prints the error to the console and moves on. This means the software doesn't "crash" anymore, just doesn't quite work perfectly. 3) There is some unimplemented CSS behaviour to look at too. Now I'll go and fix all the other issues as well. But this explains the long mystery of why some "crashes" don't produce a dump file. The reason is they aren't really crashes, just CRT exceptions that aren't handled. Ugh. |
| Scott 12/12/2016 12:07am | Build 31 works nicely with the rogue email.
I suspected that unhandled exceptions might be an issue. Exception handling is a different paradigm, similar in concept to the BASIC "goto error" statement. The main downside is that they have to be fully embraced, or they fall apart (as you noticed). If exceptions are embraced whole-heartedly, the code does actually look cleaner. Check out "Resource allocation is initialization". |
| Reply | |