With the odrive sync client installed, Calibre (an ebook management software) throws an unhandled exception whenever a file open dialog is shown.
According to the developer of Calibre, some other program is apparently injecting code into the file open dialog.
My own testing has shown that the problems start happening as soon as odrive is installed.
Relevant bug on calibre bug tracker: https://bugs.launchpad.net/calibre/+bug/1552016
odrive does not inject code into the file open dialogs but we do provide an explorer context menu extension and icon overlay extensions which explorer loads (for the badges and right click menu’s). Do you see checkmark badges and right click options working properly for you from explorer using odrive? Not sure how calibre is launching the file open dialog.
I do see the badges properly from explorer, it’s just that with odrive installed, calibre is crashing on the file open dialog. I’m not the developer for calibre, so I would suggest the developers of the odrive sync client to confer with the calibre developer to resolve this issue… it is incredibly annoying.
Heck If anything having that explorer extension loaded into calibre may just be the cause of it, since after I uninstalled odrive, I needed to restart the explorer process before calibre would stop crashing. I’d say that extension is probably one of the causes here.
Can you check one more thing, if you go to the odrive tray menu and choose move odrive folder, does a file chooser menu open without crashing? Trying to narrow down the issue.
@ruifung: I see exactly the same bug with the combination of odrive and Calibre as you do.
It appears that odrive’s usage of Python interferes with Calibre. It could well be related to the badges shown in Explorer. The FIle Open dialog from within Calibre only shows the custom badges on unsynced files (i.e. *.cloudf). No badges appear on anything else.
check out http://stackoverflow.com/questions/7769156/could-a-shell-extension-be-causing-my-program-to-crash
there may be some issues with calibre on its stack limits or something else I cannot speak on their behalf. First step would be to see if you are able to show the file chooser using odrive (through move odrive folder) or some other app that shows a file chooser besides calibre.
Showing the file chooser using odrive works fine, As for any other app, I have no idea because the only app thats crashing so far is calibre.
good to know there is no issues with that, I have tested other apps such as google chrome and no crashes, ill test some more and see if there is anything we can do on our end.
I have run into this problem as well. There is a temporary workaround that doesn’t involve removing odrive - a program called Shell Extension Viewer. This program allows you to temporary (or permanently) disable shell extensions. It shows three listed for odrive, and if I disable them, Calibre works fine. So, for the moment, until a better/more permanent solution comes along, I will disable them when I use Calibre for anything that requires a file browser dialog, and re-enable them at other times.
But it sure would be nice to have a definitive solution to the problem.
Since we aren’t seeing this issue with the file chooser instances in other applications (I’ve tried many to test), it would seem to be manifested due to something specific that Calibre is doing with their file chooser window. I don’t think there will be anything that we can practically do from our side on this.
For those of you that are communicating with Calibre on this, please tell them that they can ping us on this too, if they have questions or ideas.
in general I think they need to be aware that if they open a chooser window in their app there will be other shell extensions that WILL load, ours and other programs, and whatever the issue is be it stack limits or other issues they need to be accounted for
Quote from Kovid Goyal (Calibre’s author):
Sigh. I already told them how to fix it in the previous post. They have two options:
- Learn to write code that does not crash, but instead fails gracefully.
- If they cannot do that, stop injecting code into other peoples processes. I even told them how to do that in my previous post – create two DLLs, the first a loader DLL that checks if the process name is explorer.exe, and only then loads their actual DLL.
I will simply tell calibre users who encounter this problem to uninstall this software. Running software from people who think it is OK to insert code into other peoples processes and then blame those other people for crashes their code causes is not a good idea, who knows what other crazy things it does.
Oh and just for completeness, since they dont seem to understand the cause of this crash in their code.
Their problems are caused by the fact that they are embedding a python interpreter in their shell extension DLL. python interpreters use global variables, they are not designed to have multiple instances running in a single processes’ address space. (Technically you can use something called sub-interpreters, but that does not apply here). Their DLL is going to cause all sorts of problems from crashes to memory corruption in any application that uses python (as calibre does).
Writing shell extensions in python is a really bad idea. If they insist on doing it, they need to limit their extension to only run in explorer.exe, as I described before.
ok clearly the author of calibre does not care about catching unhanded exceptions even when it is crashing his application and when he knows he is opening a file open dialog that will inject a whole bunch of stuff into his process including another dll with a python interpreter embedded. Dropbox and google drive are both written in python and guard against this as do we. Since he refuses to catch unhanded exceptions we have patched our bootloader to catch the exceptions for him so it should no longer be an inconvenience to you guys =) the next release of odrive will have a fix for this. as for his attitude that something he will have to fix for himself =) lol
Hi, the fix that Roop described is out now… Can you try downloading the latest build from https://www.odrive.com/add-ons/sync and giving it a shot? Let us know if it solved your problem.
Thanks,
-Jeff
@Jeff_Lin: Calibre’s File Open dialog still throws errors with odrive v5085
It is in 5095: New desktop and web releases today! (03-16-2016)
This hasn’t been pushed to the autoupdater yet.
@Tony, @Jeff_Lin: Whoops. Downloaded and installed v5095 manually. No more weirdness with Calibre. Looks like you folks successfully mitigated a bug in another guy’s product!
Turns out I spoke too soon. If Calibre x64 is already installed, you can add books to a library without crashes. New installations crash on Win 10 x64. Any other operations that raise file open dialogs also throw errors. Trying to navigate to a new folder from some Calibre x64 dialogs crashes the program entirely.
There still must be something weird with odrive’s explorer icon injection via python. No other program I have tried that does the same thing, e.g Dropbox client, etc. cause any issues with Calibre. Only odrive. If odrive’s shell injections are disabled, Calibre functions without a hitch.
A workaround is to use the 32-bit Calibre client instead. No crashing problems.