SD card delete issue

[Fatty-Dogface]

Deleting files from an SD card by moving or deleting is causing Rox-filer and the pinboard to crash. Using a different file manager on the same system does not have the same result. OS is Fatdog64. Thanks for your time and effort!

[jun7]

Thank you for reporting. Is there any error log? I can't reproduce it.

[Fatty-Dogface]

I can attempt to reproduce it and check for an error log. Forgive my newb-ness, but is there a particular rox-filer log?

On 07/15/2017 01:57 AM, jun7 wrote:

Thank you for reporting. Is there any error log? I can't reproduce it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jun7/rox-filer/issues/158#issuecomment-315520696, or mute the thread https://github.com/notifications/unsubscribe-auth/Acyj5gFLdFPVtlc3lOIfT3dAMe_XFqCvks5sOH8QgaJpZM4OY3RS.

[jun7]

On systems using systemd, stack-trace are logged when app crashed. But seems fatdog64 hasn't systemd. may be it is in /var/log, sorry I don't know fatdog64 well.

[Fatty-Dogface]

jun7,

although this has happened to me several times over the last few months, I am currently unable to duplicate it. I am sorry to have bothered you about it, and I thank you for your time just the same.

For what it's worth, Fatdog64 is an offshoot of Puppy, and rox is loved in that community!

On 07/15/2017 05:12 PM, jun7 wrote:

On systems using systemd, stack-trace are logged when app crashed. But seems fatdog64 hasn't systemd. may be it is in /var/log, sorry I don't know fatdog64 well.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jun7/rox-filer/issues/158#issuecomment-315572012, or mute the thread https://github.com/notifications/unsubscribe-auth/Acyj5pQhmOtqJwRctTa_H1osrkFL2q-6ks5sOVVcgaJpZM4OY3RS.

-- Dan Sellers Sent from Fatdog64

[jun7]

Not a bother. I know reporting is not so easy. Thank you!

[step-]

Hi @jun7,

I came here to report an issue that looks similar to @Fatty-Dogface's, mine's on Fatdog64 too. Fatty-Dogface's is almost certainly running the standard Fatdog64-710 build, which is based on commit 57f6c5f. I'm running my own build, which is based on the latest commit 7df6634. Here rox crashes with the following terminal output:

(ROX-Filer:25790): GLib-ERROR **: gmem.c:100: failed to allocate 18446744072485169510 bytes

Basically it takes up all available system memory (I can see that with htop), then it crashes when alloc fails. I can reproduce this almost always with an external USB 3 drive. I open two rox windows in two different folders of the same drive. Each folder has 250+ sub-folders in it, and no files. Then I drag a folder icon between the two windows and drop it waiting for the context menu to show up. But most of the times the context menu doesn't show up and the folder icon sticks to the cursor. At this point I know that Rox has started allocating all available memory. After some time, maybe 20 seconds, the folder icon goes back to the source folder with an animation. It doesn't drop into the target folder, that is. So I try to drag-and-drop it again but it fails in the same way. After two or three failed drag-drops Rox crashes and the pinboard disappears - of course, since there is no background ROX-Filer process anymore to hold the pinboard. So I think the key to reproducing this issue is to use some sort of (slow) external media, to drag and drop from within that same media, and to hold hundreds of folder icons in both source and target directories. Icon size is 'auto' in my case, and the view is 'no details'.

---

@Fatty-Dogface, are any elements of my description similar to yours? Can you tell us if Rox fails allocating memory? To do so, provided that you can find a way to reproduce the crash, do as follows:

. After Rox has crashed, restart it from a terminal and keep the terminal window open. When it will crash again, it could print something to the terminal. To start rox from a terminal - after the crash, when there is no pinboard - type:

rox -p ~/.config.mine/rox.sourceforge.net/ROX-Filer/PuppyPin

If any drive icon is missing, right click another drive icon and select "Redraw all icons".

[jun7]

I could not reproduce it. Does it only happen in this fork of rox?

[step-]

It happens in the Fatdog64 fork, which is this fork + some patches that have been around for several years and never gave problems. Sudden crashes happen to other Fatdog64 users too. I just had another kind of crash, without memory over-allocation. This time I was dragging two files between to windows in detailed view mode. All crashes that I have experienced and heard of from other people involve drag-and-drop.

[Fatty-Dogface]

I took some time to try to duplicate both my former problem, and step's problem, without "success". I can verify his supposition that I am using the standard build of Fatdog64 710, so far as I know, i.e. I wouldn't know how to have any other, other than the beta or rc releases. While I notice various irregular glitches here and there, the OS and rox-filer seem to be functioning properly.

Dan Sellers /sent from Fatdog64/

On 09/15/2017 07:53 AM, step wrote:

It happens in the Fatdog64 fork, which is this fork + some patches that have been around for several years and never gave problems. Sudden crashes happen to other Fatdog64 users too. I just had another kind of crash, without memory over-allocation. This time I was dragging two files between to windows in detailed view mode. All crashes that I have experienced and heard from other people involve drag-and-drop.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jun7/rox-filer/issues/158#issuecomment-329805884, or mute the thread https://github.com/notifications/unsubscribe-auth/Acyj5n1sKgd9a8-r_IX8SDDoLrzemMOiks5sio99gaJpZM4OY3RS.

[jun7]

So, are there more conditions? I tested on old 8GB USB2 drive and USB3 drive but it dosen't happen.

[step-]

I'm afraid I can't find any more conditions. I don't have a sure way to reproduce this issue, but it happens quite often to me. It's quasi-reproducible on my hardware.

Can you give me some ideas on how I could debug this problem in the source code itself? Maybe you have some debug routine specific to the development of rox... I would be particularly interested in tracing what happens during a drag-and-drop operation, because that's when rox fails.

[jun7]

I have got a massive memory leak on drag and drop but with a file not a dir. the 57f6c5f is undo of the work around about it. So checking the function drag_data_get of dnd.c is not bad. At least, un-doing 57f6c5f may stop memory leak.

The dragging process has following steps in dnd.c. maybe ;P

0. drag_one_item starts dnd.
1. when a dir is droped, drag_drop is called.
2. drag_drop calls gtk_drag_get_data.
3. gtk_drag_get_data emits drag_data_get
4. gtk_drag_get_data emits drag_data_received
5. drag_data_received calls got_uri_list
6. got_uri_list calls prompt_action
7. prompt_action shows the context menu doesn't show up in the case.

So 0 - 7 are suspects. I will just add g_print("function name\n"); if it is reproduced.

[jun7]

Ah, since the dropping has animation going back, it probably fails befor step 4.

[jun7]

Addition: 'ROX-Filer/AppRun --new' runs new process. this is usefull when you are using rox. So basically my debug routine is just ./AppRun --compile > /dev/nulll && ./AppRun --new.

[step-]

Got some lucky debugging around a drag-and-drop issue similar to this one. Rox fails with

(ROX-Filer:15290): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

in display.c line 321: width = gdk_pixbuf_get_width(image); called by cell_icon.c line 375 draw_huge_icon(...);

I can reproduce the crash exactly with the following folder contents and rox view mode:

Drag the selection onto folder "history" and select Move. Some files will move but eventually rox will crash. After the first failed assertion there's a list of similar failed assertions concerning "pixbuf" then the killer

(ROX-Filer:14682): GLib-ERROR **: gmem.c:327: overflow allocating 18446744073709551615*18446744073709551615 bytes

I noticed when the crash happens the current item is always some filename.png. These are my thumbnail options:

Hopefully this time you'll be able to set up a similar reproducible case.

[jun7]

Sorry, I can't reproduce it. where is the files of the mm-view ? Dose It happen if files are not on SD card? Does the commit 1c5a5da solve it?

[step-]

The folder is in a USB3 external disk. It happens also for internal HDD (ext4). Commit 1c5a5da doesn't solve it, Rox must be in details (List button) view mode to reproduce. It also happens if the selection is dropped onto the Up button.

[jun7]

Reproduced! thank you!

[step-]

Great!

[jun7]

The crash what fixed could happen when items having a thumb are deleted. Not always though. I wonder did it happen with frequency?

[step-]

I can confirm that d1f7156 fixes the two crashes that I reported in this thread. The only glitch I noticed is that now dropping 15 files onto the test folder produces the following warning 288 times:

** (ROX-Filer:11759): WARNING **: Attempt to paste empty selection

Thanks for this fix!

I wonder did it happen with frequency?

It didn't happen frequently, but it did happen often enough to know there was a bug. Other people in the Fatdog64 forum have reported drag-and-drop crashes.

[Fatty-Dogface]

Jun7, I noticed this didn't get to you, I'm glad you seem to have found the bug.

[jun7]

So does this issue can be closed? As usual, the warnings doesn't show up on my environment ;P

[step-]

Do you know why the warnings don't show up in your environment? Is it like a Gtk-2 setting in your configuration? Anyway, I think you can close this issue. If I can solve the warnings I will open a new issue or make a pull request.. @Fatty-Dogface thanks for your follow-up.

[jun7]

I don't know why it called 288 times but the details view had lacked clearing selection. So the commit will solve the warnings but the 288 times is still not solved.

[step-]

I can confirm that 3afb8e3 hides the 288 warning messages for me.

So the commit will solve the warnings but the 288 times is still not solved.

True. I will live with this. The large number might have something to do with my layered file system (aufs). Anyway, I think you can close this issue. Thanks.

[jun7]

Thank you for reporting!