The way you created the image seems correct. Probably something is wrong or missing in our xfs code.
The error and debug messages are not very clear, so a good first step to investigating this would be adding more debug messages to the xfs code, or see if it can have extra tracing enabled at compile time (usually by defining a TRACE_xxx macro in the sourcefiles where you need tracing). Then it will be easier to see why our xfs code is nottable to understand your test file.
Can we make the changes in source file to give better error message?
For eg : when I tried to run command mkdir it has given “Command not supported yet” we could make same for XFS version 5 as well I guess, though right now I don’t know how to do that though
Anyways I will continue my testing on xfs version 4 image.
I encountered some segmentation fault on running ls on directory with 20k directories.
Its very strange though, at first I was able to read completely upto 20k but when I ran ls command again it has shown segmentation fault after reading 6k directories.
Some large directories are showing same segmentation fault : 11 error.
Looks like this error wasn’t resolve last year.
Any guide on how to fix this?
For segmentation faults, maybe you can use a debugger to investigate them, get a stack trace, and see where is the code it’s crashing.
Or just add a lot of TRACE() call everywhere in the code to see which parts of the code are run, and where it’s failing.
You can look in more details at the build logs. Probably some of the TRACE calls are incorrect and need to be fixed: wrong format strings for example (the format strings work like the ones used for the standard C printf function)
I think for now I will try to debug that segmentation fault we encountered while testing and see if I make some progress there.
If not then I will look for v5 support or maybe extended attributes feature.
Actually This is almost same as the process I applied and unfortunately gave me same results.
Anyways I tried to get GDB on my local machine and I am able to actually continue process using GDB debugger, but the problem now is whenever a segmentation fault occurs xfs_shell terminates entire process.
So when I try to reproduce segmentation fault for GDB to catch it, we can’t get any trace as xfs_shell terminates and GDB gives result as
Inferior 1 (process ___) exited normally.
If we could get xfs_shell to not terminate we can then get a backtrace.
I think I should ask this on mailing list to get other developers help as well.
I’m not familiar with how lldb works. It’s strange that gdb would not see the segmentation fault.
An option is adding code in xfs_shell to “ignore” the SIGSTOP signal and not exit when receiving it.
Another option is to start the process from inside lldb (using it’s run command) but I am not sure how easy it is to do this (since you need to replicate what “jam run” does). Maybe other developers can share their tips indeed.
In my case I run these things inside Haiku, and in that case, I can attach Haiku Debugger after the crash occurs, which is very convenient. I don’t know why this isn’t the default behavior in other systems.