core dump while changing directories

[muellerto]

Describe the bug I have a new core dump when I change directories. It seems that having a selection plays a role.

To Reproduce I have two big directory trees, A and B, very similar, side by side. I'm somewhere deep in A.

1. I select a sub directory there using its number, s 5. In my case this directory contains a lot of stuff - an entire node.js project with a lot of node packages, all in all 5.9MB in more than 1200 files. But the selection names only the directory itself, just one simple entry.
2. Then I use ..... to get up to the common root of both A and B. This is still successful.
3. When I then go down in B using just numbers, 3, 7, 1 ... it suddenly crashes and remains hanging, I must kill the process manually.

No symbolic links involved, all real directories on the same partition.

I have the impression that I can do all the directory changes (and many more) successfully when I don't have a selection. (But using the selection is the reason why I do this all ...)

Expected behavior Should not crash.

Desktop (please complete the following information):

• OS: Windows 11
• Terminal: ConEmu or DOS prompt
• CliFM version: 1.9-rc1
• Installation source: Git

[muellerto]

It's even worse: a core dump happens also when I start clifm, then it shows any directory from history, and when I then execute a simple .., that's even enough.

[leo-arch]

Hi @muellerto. Thanks for reporting!

Does this happen only on Windows? Is it crashing or just hanging?

[muellerto]

Haven't checked it until now because I'm not on my Linux machine. Need still two hours, I tell you then.

[leo-arch]

Great. In the meantime, I'll try to reproduce this issue.

[muellerto]

On Windows the application freezes and doesn't react on any keystroke (also not on Ctrl-C, Ctrl-D or something). The screen remains visible and shows a line at the bottom that a core dump is written, the file does later indeed exist. But the application never comes back, you must kill it.

[muellerto]

On Linux it seems to work fine with and without a selection, whatever I do.

But my experience is: if there's a stability problem on one platform it's probably also other platforms, you just don't see it right now.

[leo-arch]

Good to know.

if there's a stability problem on one platform it's probably also other platforms

Definitely a possibility. It all depends on whether the buggy code is shared among multiple platforms or is it specific to a single one.

For the time being, I've tried to reproduce the scenario you described on Linux: no issue at all. I'll give it a shot on Windows.

[leo-arch]

Can you please try running with a fresh/testing profile and/or in stealth mode?

clifm -P test -S

[muellerto]

Tomorrow. My Windows machine is a rifle shot away (or two).

[leo-arch]

t's even worse: a core dump happens also when I start clifm, then it shows any directory from history, and when I then execute a simple .., that's even enough.

This looks like (I might be wrong though) a corrupted directory history file (~/.config/clifm/profiles/default/dirhist.clifm). But I don't see any clear relation between this and selections.

[leo-arch]

Tomorrow. My Windows machine is a rifle shot away (or two).

Don't worry. Just thinking aloud. I'll try to intentionally corrupt the history file to see if we get something.

[muellerto]

This looks like (I might be wrong though) a corrupted directory history file (~/.config/clifm/profiles/default/dirhist.clifm). But I don't see any clear relation between this and selections.

I could delete it and see what happens. Good idea.

[leo-arch]

Just in case, rename the file instead of removing it: it if was the cause of this issue, it will be useful to debug the error. A crash is not acceptable even when caused by corrupted files.

[muellerto]

Having no dirhist.clifm doesn't change anything. I also removed .last which leads then to another initial directory but also doesn't help. These files did also look good at first glance.

The call clifm -P test -S changed the behavior. clifm -S is enough. When I run it like this everything seems to work. When I call it again without parameters I have the problem again. Do you mean I have something bad in my config file(s)?

BTW: I always just compile using make to see if it builds correctly and then I call make install to copy the files. This means I just copy the files over existing files. Is this good? I'm not sure (and I'm to lazy to search for it), is there also a make uninstall and should I use it before make install?

[muellerto]

It seems to be the option PrintSelFiles. I have this normally true (also on Linux, because the selection survives a long time and is even there after a restart - so you must know what's in it). It shows the selection correctly when this is on but seems to be the reason why it crashes on Windows some directory changes later. When PrintSelFiles is false changing directories works as expected as often as I want.

[leo-arch]

it seems to be the option PrintSelFiles

Great. At least the source of the issue is now identified. What value are you using for MaxPrintSelFiles?

I've been playing around with these options and still no luck.

[leo-arch]

Solved!

EDIT: You were right. This issue was affecting Linux as well (all supported platforms in fact).

[leo-arch]

Do you mean I have something bad in my config file(s)?

Nothing's bad with your config

I always just compile using make...

It shouldn't make any difference.

[muellerto]

Success! Works fine again, also on Windows. Thanks a lot for that.

[muellerto]

.