| Summary: | TDESVN crashes on exit | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Jan Stolarek <jwstolarek> |
| Component: | tdesdk | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | REOPENED --- | ||
| Severity: | normal | CC: | bugwatch, jwstolarek, michele.calgaro, rom_as |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Attachments: |
Stack trace
tdesvn_6.kcrash Crash at the exit Crash at some tree item drag and drop tdesvn-CrashAtClose.patch tdesvn-CrashAtClose.patch tdesvn14.1.kcrash tdesvn-CrashAtClose.patch |
||
Does the crash happen only if you choose a repository from the list of recently opened ones or any repository? It also happens when I open a repository with File -> Open. Sorry for late reply, somehow the notification email ended up in spam folder :-/ Thanks Jan, no worries for the delay :-) I have not observing more these TDESVN crashes in Qt-code, so this possible fixed already! Indeed, I can no longer reproduce this using the method described in the bug report. Thanks for the feedback both of you. So Jan, what to do with this bug? Shall we marked it resolved for the time being and you reopen it if the problem shows up again? Yes, let's close. I tried to reproduce at least a single crash but couldn't. If I run into the problem again I'll reopen. Ok, perfect! Created attachment 3019 [details]
tdesvn_6.kcrash
No, that yet crashes.
And this crash report is only one from several.
Hi Roman, thanks for the backtrace. Looking into it, the crash seems quite different from the original backtrace, so perhaps it is a different problem (still a crash of course!). Should probably be reported as a separate bug in fact. Can you share the steps to reproduce the crash of the backtrace? I want to see if I can simulate that here. > thanks for the backtrace. Looking into it, the crash seems quite different > from the original backtrace, so perhaps it is a different problem (still a > crash of course!). Should probably be reported as a separate bug in fact. I have got the crashreports on any taste from February, if you want. :) > Can you share the steps to reproduce the crash of the backtrace? I want to > see if I can simulate that here. I want also, but that is performed rare and without some specific my actions, at the exit mostly and corrupting data on QDict, what is common seems with the other bug #3164. But that was before the last 14.0.11, then I am observing and waiting now for the reproducing which have not performed yet neither for TDESVN or DCOP (#3164). > I want also, but that is performed rare and without some specific my actions,
> at the exit mostly and corrupting data on QDict, what is common seems with the
> other bug #3164.
Ok, understood. Let's keep the bug open and if you are able to reproduce it again, please let me know how and I will try to replicate here.
Created attachment 3027 [details]
Crash at the exit
I have just closed the main window.
Created attachment 3028 [details]
Crash at some tree item drag and drop
That caused when I fast-wrong drag and drop some tree item.
Created attachment 3041 [details] tdesvn-CrashAtClose.patch > Created attachment 3027 [details] > Crash at the exit Yes, and at the exit the crash have not been observed. After digging into the tdesvn code I see here using kparts which closing-exiting is very specific, that is the main program class destructor tdesvn::~tdesvn() is never executed at exiting, but that is executed at the last window close and m_part is destroyed very late with unlinking the part library firstly, and remaining some containers not free. So, in my patch I have appended of a processing function of the window closing, where calls the exiting. Now I am observing for the fix work and have seen no crash at the window close yet. Hi Roman, first of all, hope you are well with all that's happening in your country. I am installed tdesvn again and I am trying to reproduce any of the crashes in the attached dump files. I see a few different types of crashes. What is the best way to simulate this problem? Your patch seems simple and clean, so I would like to replicate the behavior here for testing. I found a way to reproduce the crash reported by Janek. Pretty much I followed the steps he suggested, just made sure to click on some files after you load a repo. I can reproduce the crash quite often, although sometimes it closes without crashing. @Roman: I tried without and with the patch you proposed in comment 15, and I get exactly the same behavior. That means that the patch does not work correctly, unfortunately :-( (In reply to Michele Calgaro from comment #16) > first of all, hope you are well with all that's happening in your country. Hi, Michele I am fine, thanks. > I am installed tdesvn again and I am trying to reproduce any of the crashes > in the attached dump files. I see a few different types of crashes. > What is the best way to simulate this problem? In my case the problem was not reproduced permanently and I achieved in the often reproducing after some debug prints appending. (In reply to Michele Calgaro from comment #17) > I found a way to reproduce the crash reported by Janek. Pretty much I > followed the steps he suggested, just made sure to click on some files after > you load a repo. I can reproduce the crash quite often, although sometimes > it closes without crashing. That seems some other and I have no crashes here now, but I have seen a like warning in valgrind: ==41183== Invalid read of size 4 ==41183== at 0x59BCE44: deref (ntqshared.h:52) ==41183== by 0x59BCE44: TQString::~TQString() (qstring.cpp:1690) ==41183== by 0x5E584D6: __run_exit_handlers (exit.c:108) ==41183== by 0x5E58679: exit (exit.c:139) ==41183== by 0x5E40D10: (below main) (libc-start.c:342) ==41183== Address 0xa4ba3b0 is 0 bytes inside a block of size 48 free'd ==41183== at 0x483A08B: operator delete(void*, unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==41183== by 0x5E584D6: __run_exit_handlers (exit.c:108) ==41183== by 0x5E58679: exit (exit.c:139) ==41183== by 0x5E40D10: (below main) (libc-start.c:342) ==41183== Block was alloc'd at ==41183== at 0x4838DEF: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==41183== by 0x59BE3C6: TQString::setLength(unsigned int) (qstring.cpp:1911) ==41183== by 0x59C12EF: TQString::operator+=(TQString const&) (qstring.cpp:5793) ==41183== by 0x95E76AA: tdesvnPart::createAboutData() (tdesvn_part.cpp:160) ==41183== by 0x95E978A: cFactory::instance() (tdesvn_part.cpp:436) ==41183== by 0x95E6E80: tdesvnPart::init(TQWidget*, char const*, bool) (tdesvn_part.cpp:81) ==41183== by 0x95E6DBB: tdesvnPart::tdesvnPart(TQWidget*, char const*, TQObject*, char const*, bool, TQStringList const&) (tdesvn_part.cpp:73) ==41183== by 0x95E9650: cFactory::createAppPart(TQWidget*, char const*, TQObject*, char const*, char const*, TQStringList const&) (tdesvn_part.cpp:418) ==41183== by 0x11AD1B: tdesvn::tdesvn() (tdesvn.cpp:117) ==41183== by 0x118CD9: main (main.cpp:74) Created attachment 3043 [details] tdesvn-CrashAtClose.patch > @Roman: I tried without and with the patch you proposed in comment 15, and I > get exactly the same behavior. That means that the patch does not work > correctly, unfortunately :-( Try the new patch please, which fixes the valgrind error in strange using the method m_Extratext as the static one in the unlinking kpart library. > Try the new patch please, which fixes the valgrind error in strange using the > method m_Extratext as the static one in the unlinking kpart library. The part related to "m_Extratext" seems good and based on the backtrace it probably fixes this issue. Not sure if we need the part related to "close event". I was able to crash tdesvn with the patch you initially proposed in comment 15 (see comment 17), but with the latest patch it seems much more stable. I will try using only the part related to "m_Extratext" and see if I don't have any more crashes. If so, I will merge into master and R14.0.x. I have pushed the changes related to "m_Extratext" in commit 1f18406 and also backported it to R14.0.x. @Roman: I have credited you as author, since the patch comes from you. I have also signed that off in your name. It seems that tdesvn does not crash anymore on exit with this change, at least I could not reproduce the crash anymore. Could you test and confirm if that is the case for you too? (In reply to Michele Calgaro from comment #22) > I have pushed the changes related to "m_Extratext" in commit 1f18406 and > also backported it to R14.0.x. OK, but better you use the patch in 3043 completely, since "m_Extratext" fixes the common KPart unlinking and all other do that exit in common way whether by the menu item "Exit" or the last window closing, where the crash can appear also! > @Roman: I have credited you as author, since the patch comes from you. I > have also signed that off in your name. Yes, I see. > It seems that tdesvn does not crash anymore on exit with this change, at > least I could not reproduce the crash anymore. Could you test and confirm if > that is the case for you too? With the completed patch and from 2022-06-02 I see no crash on exit and once see a crash at drag and drop what is absolutely different and very rare problem for catch directly. Hi @Roman, forgive me for asking, but I struggle to understand why the remaining part of the patch would prevent a crash. The getMemberList() method returns a pointer list of the TDEMainWindows associated with the application. A new TDEMainWindow is added to this list when the window is created and removed from the list when a window is destroyed. If the last TDEMainWindow of an application gets closed, the application gets terminated. This is the same for any TDE application. why do we need to explicitly call kapp->quit() and why would this prevent a crash (which now does not seem to happen anymore by the way)? Re the crash with drag-and-drop, it is indeed a different thing, I have seen it as well :-) (In reply to Michele Calgaro from comment #24) > forgive me for asking, but I struggle to understand why the remaining part > of the patch would prevent a crash. The getMemberList() method returns a > pointer list of the TDEMainWindows associated with the application. A new > TDEMainWindow is added to this list when the window is created and removed > from the list when a window is destroyed. If the last TDEMainWindow of an > application gets closed, the application gets terminated. This is the same > for any TDE application. why do we need to explicitly call kapp->quit() and > why would this prevent a crash (which now does not seem to happen anymore by > the way)? I have observed the containers freeing very deeply and did not see there any memory leak what can cause to the GDict containers leaving with the related crash. But I saw a difference in exiting from the menu item Exit and the last window closing, what you can read in the comment #15. And this difference you visually can observe in the exiting time, where the menu item Exit is ten times longer on big projects, so some KPart objects can to not free at the last window closing and cause such kind crashes without tracing since the KPart library was unlinked already and the objects remain in memory. Created attachment 3064 [details]
tdesvn14.1.kcrash
Now in 14.1.0 TDESVN crashes always at the exit!
Created attachment 3065 [details]
tdesvn-CrashAtClose.patch
And this patch fixes the new crash issue, which appeared due to loading the DB plugins of Qt in a KPart, so when the KPart library unloaded with the plugin libraries, the DB objects of Qt is left without source!
I have observed no crash after updating to 14.1.1, so it was fixed, seems. But I am going to watch yet month and then close the issue. Sounds good. |
Created attachment 2962 [details] Stack trace Steps to reproduce: 1. Open TDESVN 2. Open a repository by selecting one from the list of recently opened URLs (in File menu) 3. Close TDESVN (either File->Quit, Alt+F4, or "x" button) Crash happens always, at least with the repository that I'm using. Attaching a stack trace. Possibly related to/a duplicate of #1549.