search

giuspen / cherrytree

cherrytree
https://www.giuspen.net/cherrytree/
Other
3.45k stars 468 forks source link

gdbus.exe has stopped working - error message after closing a Cherrytree file in version 1.2.0 #2579

Open Atlntssplayer opened 1 month ago

Atlntssplayer commented 1 month ago

Version, Operating system Cherrytree version 1.2.0 (both nolatex and normal portable releases) Windows 7 x64

Describe the bug Using Cherrytree version 1.2.0 after closing a .ctd file I get the error message from Windows that "gdbus.exe has stopped working". This happens even after just opening and closing a Cherrytree document without modifying anything in it. Happens with the nolatex and normal versions too. I only tested the portable releases, cherrytree_1.2.0.0_win64_portable.7z and cherrytree_1.2.0.0_win64_portable_nolatex.7z. I also tested the following older versions for this bug and it didn't happen: 1.1.4, 1.1.3, 1.1.2, 0.39.4 I tested with 2 different documents, a smaller one with about 20 nodes and a big one with about 1900 nodes and the bug happened with both.

To Reproduce If applicable, attach a non-personal document where the issue can be reproduced systematically. Steps to reproduce the behavior:

  1. Open .ctd file with Cherrytree version 1.2.0
  2. Close Cherrytree
  3. gdbus.exe has stopped working error happens.
giuspen commented 1 month ago

Hello @Atlntssplayer and thanks for reporting. I'm not seeing this on Windows 11, I will try later on a Windows 10. gdbus.exe / DBus ( https://en.wikipedia.org/wiki/D-Bus ) is used from cherrytree to communicate between the first and the subsequent instances. Typically every instance (when you open a file or just start from the menu) tries first to talk to an already existing instance to "pass the ball" and exit instead of having many independent instances running. It's not something you should worry too much because the worse that can happen is that you have more than one instance of cherrytree running on the same file independently, but if I can reproduce it I will look at why is doing so. Unfortunately I don't have a Windows 7, I'll see if we can reproduce at least on a Windows 10.

giuspen commented 1 month ago

Also tested on a Windows 10, could not replicate the issue.

Atlntssplayer commented 1 month ago

Thanks for looking into it. If it can't corrupt the opened file than I'm not worried.

I have WinDbg installed and used it before to get a stack trace for devs of another software that was crashing. Maybe I can use it in this case too if you can't reproduce the problem on your end. I would need symbol files for it though. I'm not a dev myself so I don't really know how things work. Anyway if I can help more feel free to tell me what to do. I love Cherrytree. :)

giuspen commented 1 month ago

No worries @Atlntssplayer as it's not dangerous and probably only happening on Windows 7, if you are curious yourself and want to dig this further, you would have to try and build/run from the sources as described in https://github.com/giuspen/cherrytree/blob/master/BUILDING.md#building-cherrytree-on-windows - Take care ;)

metal450 commented 1 month ago

I'm seeing this too, on Windows 10 1809. gdbus.exe crashes shortly after exiting CherryTree 1.2.0 each time.

metal450 commented 1 month ago

Also: I'm using a multi-file db, not ctd

giuspen commented 1 month ago

Thanks for reporting @metal450 are you also using a portable version or you have it installed?

metal450 commented 1 month ago

Installed

csttsn commented 1 month ago

Having the same issue, W11 Pro with all latest updates, portable version, gdbus.exe crashes after closing the Cherrytree (you can view the error description in "Problem Reports" in the Control Panel).

Source gdbus.exe

Summary Stopped working

Date ‎09-‎Oct-‎24 18:25

Status Report sent

Description Faulting Application Path: C:\Utilities\CherryTree\mingw64\bin\gdbus.exe

Problem signature Problem Event Name: APPCRASH Application Name: gdbus.exe Application Version: 0.0.0.0 Application Timestamp: 6700188c Fault Module Name: libglib-2.0-0.dll Fault Module Version: 2.82.1.0 Fault Module Timestamp: 67001889 Exception Code: 40000015 Exception Offset: 00000000000c1085 OS Version: 10.0.22631.2.0.0.256.48

B-Down commented 1 month ago

Same here with W7, portable (w/LaTeX), gdbus error a few seconds after closing CT.

Since I never had that "issue" with previous versions (I used 1.0.4, 1.1.2, 1.1.4, all portable), I did some science of my own, if that can be of any help (either to pinpoint the error, or merely get rid of it)...

I copied the following files from 1.1.4 to 1.2.0:

There may be more (or even less) files pertaining to gdbus, but copying those over made that error disappear (or, well, not appear 😉). I didn't see any difference with those "new" files, but I didn't test it thoroughly: I went through a number of menus, parameters, opened a couple ctd files... everything seems ok so far.

Edit: Fun fact, I only just noticed csttsn's message mentioning libglib-2.0-0.dll being at fault, but I didn't touch that one... 🤷

Fun fact #2: with my files-wrangling, gdbus.exe doesn't get killed when CT is closed.

csttsn commented 1 month ago

I copied the following files from 1.1.4 to 1.2.0:

Tried replacing only libglib-2.0-0.dll with the version from 1.4, but the program does not start. So I decided to revert back to 1.1.4 for now, which is working flawlessly. I hope giuspen will manage to find the cause of this crash.

giuspen commented 1 month ago

@B-Down if you take only gdbus.exe from 1.1.4 and overwrite it into 1.2.0, is the crash still happening? Your help here is very useful since I cannot see the crash myself, it seems to me clear it's a library/msys2 platform component issue and if you help me to cherry-pick the minimum older component to revert I can then submit here a new bundle so that who has the crash can try it and confirm that it works for them too.

B-Down commented 1 month ago

@B-Down if you take only gdbus.exe from 1.1.4 and overwrite it into 1.2.0, is the crash still happening?

It does, with the very same error.

Tried replacing only libglib-2.0-0.dll with the version from 1.4, but the program does not start

Well, you quoted one line from my message and seemed to have ignored the rest of it (I listed all the files I replaced and specified that I didn't touch libglib), so no wonder you didn't get the same result... 🤷

csttsn commented 1 month ago

Well, you quoted one line from my message and seemed to have ignored the rest of it (I listed all the files I replaced and specified that I didn't touch libglib), so no wonder you didn't get the same result...

I just wanted to test whether replacing this one file will solve the issue, since it is mentioned in the crash log, but looks like it is a part of the larger component that was updated, since, for example, additionally replacing gdbus.exe does not help either. I'm amazed you managed to quickly figure out the full list of files to be replaced to avoid the crash.

B-Down commented 1 month ago

I just wanted to test whether replacing this one file will solve the issue

When you put it that way, it makes perfect sense 👍

As for "figuring out" the files, it was merely a process of elimination: I first tried with only replacing the two "obvious" files (gdbus.exe and gdbus-codegen.exe), but since that didn't end too well (it stil produced the error), I dug a bit more about which files could be about gdbus... As mentioned in my initial message, I probably didn't catch 'em all, and the end result isn't completely satifactory either, with gdbus.exe not existing after CT is closed, so here's hoping @giuspen can figure it out 🤞

giuspen commented 4 weeks ago

Anybody experiencing this issue after closing cherrytree, could try https://www.giuspen.net/software/cherrytree_1.2.0.0+13_win64_portable.7z and report if it still happens?

metal450 commented 4 weeks ago

Looks like that fixes it

B-Down commented 4 weeks ago

CT doesn't launch at all for me (W7) with this version: not a single process appears on the task manager, no errors anywhere to be seen (including the event viewer).

giuspen commented 4 weeks ago

I didn't really apply any change for this issue in cherrytree, I simply noticed that msys2 released a new glib2 package https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-glib2 (together with other updates) and rebuilt cherrytree with that. Unfortunately it doesn't look like windows 7 is supported anymore https://www.msys2.org/docs/windows_support/

giuspen commented 4 weeks ago

Actually I'm wrong, it is stated: Mingw Toolchains: MINGW32/MINGW64 environments allow targeting Windows 7+ still. All others allow targeting Windows 8.1+. And CherryTree is MINGW64 it should still be supported.

B-Down commented 4 weeks ago

And CherryTree is MINGW64 it should still be supported.

Be that as it may, I'm still not getting any response whatsoever from executing the .exe in that version.

I did try to copy some files over from the regular 1.2.0.0 (the *glib* files in mingw64\bin, then the .exe itself), to no avail.

Unless you have some way(s) of generating logs for it, I can't even tell you what could be the issue on my end 🤷 It would help to have feedback from other W7 users (@Atlntssplayer ?) as well.

B-Down commented 4 weeks ago

I did some deeper digging with the help of Dependency Walker, logs at the bottom of this message. The "tests" were on the latest 3 versions: 1.1.4.0, 1.2.0.0, 1.2.0.0-13.

I'm not a developer in any capacity (more so on Windows), so the depth of my "analysis" is limited.

Points of interest:

depwalk_CT_1.1.4.0.txt depwalk_CT_1.2.0.0.txt depwalk_CT_1.2.0.0-13.txt

metal450 commented 8 hours ago

Should we be unzipping the build above over our installed CherryTree for now? Is that the best approach (until there's a new version with the fix)?