Is there a procedure to start a program in a step by step manner to observe problems in loading?

I am still trying to diagnose segfaults of loading dconf-editor. I am unable to find any reference for a procedure to load that program in a step-by-step manner to see what process is throwing the segfault.
I think I could get a handle on the situation using such a procedure.

Perhaps that info is in the coredump. I will also look at how to diagnose those but I think that is a big learning curve to climb. Looking for a simpler alternative.

thanks, tom kosvic

start from command line should report errors

I am not sure from your post whether you have tried to start it in a console. If not, that would be my first step as that normally generates useful error messages. If you have tried that, sorry I cannot help you any further.

The TO is refering to this post:

@tckosvic Install the debug packages and run gdb
https://en.opensuse.org/openSUSE:Bugreport_application_crashed#Using_GDB

As I posted in my initial thread on this subject. The below is what I get in a terminal.

(base) tom@mydesktop: ~ $ dconf-editor
Segmentation fault (core dumped)
(base) tom@mydesktop: ~ $ 

There is no useful info.
I am not getting error on gconf-editor. I am using mate desktop where I have the problem. If I logout/login to gnome classic, dconf-editor runs fine.

Will try the gdb packages. Need to do some studying of those.

thanks, tom kosvic

That’s easy … and has been around for a l-o-n-g time with Linux systems - at a command line, run this:

:> nohup strace dconf-editor > dconf-trace.txt  2>&1

You can change the name of “dconf-trace.txt” to whatever you prefer. It’s the filename that is created and contains all the calls that happen with the run of “dconf-editor”.

Obviously, someone with “software engineer” (programmer) experience can identify the issue. But you could post the complete output of that file here, using the “paste” feature.

2 Likes

gdb may be the better choice to debug a segfault. But if needed, the output of both commands may be attached to a bugreport.

I ran the suggested “strace” string. I see a problem in the dconf-trace.txt file right away.

For some reason, dconf-editor call is looking for a process in openfoam (a cfd program) directories in my home which it shouldn’t. I think the root of my problem is within the env/path setup I am using.
Many paths are set for openfoam functions.

Thanks for the “strace” analysis string. I think I can diagnose the cause of my issue from here.

tom kosvic

1 Like

I’m glad you’ve narrowed down the potential problem. We use the “strace” on numerous problems. It’s very useful, if you can read the output. Quick and easy.

Fortunately, I have a software engineer here to help diagnose :slight_smile:

1 Like

Dconf-editor now loads in mate. I needed to deactivatre “anaconda python”, i.e., exit the base environment. The anaconda commands put into .bashrc were altering the path so that the system was looking for libconf1 (a dependency of dconf-editor) inside a wrong directory in my home instead of the system libconf1 needed to run dconf-editor.

Who would have thunk that? Without “strace” string provided by @aggie, I would have never had the information to even get close to properly diagnosing the issue.

tom kosvic

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.