I'm using PCManFM 1.2.3 and on making some tests with SciTE I have noticed that entering its extracted directory, leaving it and then deleting it causes PCManFM to crash. Here are the reproduction steps:
After the last step PCManFM does crash but I'm also noticing that a few files in the extracted directory got deleted.
Anonymous
I cannot reproduce your issue on my machine, and in any case extracted files are just files, nobody reported any crashes on deletion of a directory before and there should be none anyway. In any case, crash is a very bad thing, could you make a coredump available to explore it, please? Thank you very much.
I'm noticing that this issue only appears if side_pane_mode is set to dirtree.
I've tried both Places and Dir.Tree modes for side pane, still no crashes for me.
In the attachments is a log with GDB. The issue hasn't also appeared always with GDB so there could be maybe a race condition.
Last edit: Sworddragon 2015-06-02
The memory corruption is a very bad thing. I would like to ask you to run pcmanfm under valgrind:
That will run pcmanfm very slowly due to checks on all memory operations. Could you do it, please? Your libfm version is 1.2.3, right? I suspect the culprit lies outside of libfm though, but anyway only memory examination may tell that for sure. Thank you in advance.
Yes, I'm also on LibFM 1.2.3. I have now tested this with Valgrind but the crash doesn't appear there.
Of course, it will not crash under valgrind, it will write an alert into log file (or onto console if log file not stated in the command line) instead and I pretty much want to see its log, please! Thank you in advance!
Last edit: Lonely Stranger 2015-06-03
If PCManFM will not crash on Valgrind shouldn't it at least freeze or something similar if this issue appears? As I was able to repeat the reproduction steps 10 times without noticing something suspicious which made me thought that this issue doesn't trigger on Valgrind.
No, valgrind just supresses write when processor attempts to write data into invalid place, without valgrind it corrupts memory chain and program crashes instead. The logfile contains all the analysis on invalid access (similarly to the debugger but debugger doesn't prevent memory corruption while valgrind does).
I have tested this now again but I'm seeing only on opening PCManFM a few entries like "Invalid read of size 1" and "Address 0xc9fbd80 is 0 bytes inside a block of size 17 free'd" which do always point either to libglib or libgio at the last line. On trying to reproduce the issue Valgrind does never show any additional errors.
Do you use --trace-children=yes --track-origins=yes options for valgrind, right? That is pretty much strange. And I still would like to see whole log (from very start and up to point you close pcmanfm using 'pcmanfm --desktop-off') please. Thank you in advance.
Yes, I have used the requested options. In the attachments is the full log on trying to reproduce the issue one time.
Unfortunately that valgrind log doesn't seem to give any useful data. It might depend on some timed sequence so doesn't reveal itself. Could I ask you to do some more research, please? I would like to ask you to install glib and libfm debug symbols (libglib2.0-0-dbg and libfm-dbg) and get another backtrace. Thank you in advance.
Here is the log with all debug symbols (libfm-dbg, libglib2.0-0-dbg and pcmanfm-dbg).
I suspect this issue to have the same cause as [#1033], so it is fixed now in GIT sources. I would like to ask you to test it thoroughly (PPA repository has the fix) and give a feedback whether it's fixed or not. Thank you very much in advance.
Related
Bugs: #1033
Just as a clarification: beforementioned bug is fixed in libfm.
With PCManFM 1.2.5 and LibFM 1.2.5 I was able to reproduce the crash after a few deletion tries.