Compiling, debugging: How do I know what compile settings devuan uses?

Eeqmcsq · 2017-09-20 09:31:21

Caja is the MATE desktop's file browsing app. I want to compile and debug caja to fix a crash I found. However, my compiled caja looks different than devuan's installed caja. My caja has no menu, no toolbar, and no keyboard shortcuts.

I followed the warning message: "Unable to load ui file caja-shell-ui.xml" through the code. Eventually, I figured out that for my compiled caja, the DATADIR macro was defined as "/usr/local/share". But caja installs its files under "/usr/share".

The solution is that when I run autogen.sh to create the Makefile, I specify the DATADIR path, like this:

./autogen.sh --datadir="/usr/share"

But my larger question is: If I want to be sure my compiled code is the same as Devuan's compiled code, how do I know what cmd line options Devuan used to compile code? This is not just for caja, but for any other package I might compile and debug in the future.

fsmithred · 2017-09-20 13:58:04

Could be a trick question, so I'll give the trick answer first - Devuan didn't use any compile options. Now I'll explain.

Caja is not a devuanized package. You can tell by looking at the version number, which does not have "devuan" appended to it. So it's exactly the same package that debian provides. The compile options can be found in the rules file of the source package, and you can get the source package with the command (as unprivileged user)

apt-get source caja

(Make sure you have deb-src lines enabled in /etc/apt/sources.list)

There are good instruction for what to do with that source package here -
http://forums.debian.net/viewtopic.php?f=16&t=38976

If you do it this way and make a .deb package, then the package manager will know that it's installed. That might be helpful with getting dependencies or if you ever want to install something that depends on caja.

greenjeans · 2017-09-20 20:45:32

Eeqmcsq wrote:

Caja is the MATE desktop's file browsing app. I want to compile and debug caja to fix a crash I found. However, my compiled caja looks different than devuan's installed caja. My caja has no menu, no toolbar, and no keyboard shortcuts.
I followed the warning message: "Unable to load ui file caja-shell-ui.xml" through the code. Eventually, I figured out that for my compiled caja, the DATADIR macro was defined as "/usr/local/share". But caja installs its files under "/usr/share".
The solution is that when I run autogen.sh to create the Makefile, I specify the DATADIR path, like this:
./autogen.sh --datadir="/usr/share"
But my larger question is: If I want to be sure my compiled code is the same as Devuan's compiled code, how do I know what cmd line options Devuan used to compile code? This is not just for caja, but for any other package I might compile and debug in the future.

Curious if you located the source of the crash (bug) and what it was?

Several bugs in caja that I have lived with for years going back to when it was nautilus in gnome2. But it never crashes on me, that sounds more like dconf crapping out (again).

Eeqmcsq · 2017-09-20 22:52:46

Could be a trick question,

Nope, it's not a trick question. I didn't want to waste my time debugging a problem that ended up being a configuration or compiler option.

I've done the same thing at work when I write my own compiling scripts on my local PC - I check what the build scripts do on our build server and make sure my local build scripts use the same config or compiler defined options. This ensures my local builds that I debug with are the same as the ones the customers get.

For example, if my local build had a TIMEOUT variable of 30 sec, but the customer build had a TIMEOUT of 1 sec, my local build will never see the customer's problem. That's what I'm trying to avoid and why I wanted to know how devuan builds the packages.

apt-get source caja

Yeah, I got the source code using this command. I can see that the command downloaded the original caja.1.8.2 source and some debian patches, which the command automatically applied.

Curious if you located the source of the crash (bug) and what it was?

Nope, not yet. That's coming up next once I ensure that my compiled caja has the same settings as the installed caja.

The steps to reproduce the crash:
- Open any caja file manager window.
- Press F3 to open a split pane.
- Press F3 to close the split pane.
- Go to the menu: Edit > Preferences.
- Crash.

This problem doesn't occur in Nautilus 2.30.1 (on Ubuntu 10.04).

greenjeans · 2017-09-20 23:00:31

Eeqmcsq wrote:

The steps to reproduce the crash:
- Open any caja file manager window.
- Press F3 to open a split pane.
- Press F3 to close the split pane.
- Go to the menu: Edit > Preferences.
- Crash.

Not happening here. Cannot reproduce on two different machines.

I think I would have tried re-installing before I went to the trouble of compiling my own. I can't remember Caja ever crashing on me now that I think about it. And believe me, I do some crazy crap with it, and constantly.

Last edited by greenjeans (2017-09-20 23:05:03)

Eeqmcsq · 2017-09-21 19:40:36

Not happening here. Cannot reproduce on two different machines.

I just discovered that this crash only occurs in List View. It does not occur in Icon View, or Compact View.

fsmithred · 2017-09-21 21:03:13

I don't know if it's related, but thunar has a similar bug. Sometimes it locks up when it's in detailed list view. If I catch it soon enough, I can press ctrl-1 or ctrl-3 to change to icon or simple list view or else close the window by clicking on the x in the corner. If I wait, it totally locks up and has to be killed from command line. It's a known bug in thunar that's been around for years.

golinux · 2017-09-21 21:30:08

fsmithred wrote:

I don't know if it's related, but thunar has a similar bug. Sometimes it locks up when it's in detailed list view. If I catch it soon enough, I can press ctrl-1 or ctrl-3 to change to icon or simple list view or else close the window by clicking on the x in the corner. If I wait, it totally locks up and has to be killed from command line. It's a known bug in thunar that's been around for years.

Hmmmm . . . I ALWAYS use detailed list view in thunar and have NEVER had it lock up. Go figure . . .

greenjeans · 2017-09-22 20:44:14

Eeqmcsq wrote:

Not happening here. Cannot reproduce on two different machines.
I just discovered that this crash only occurs in List View. It does not occur in Icon View, or Compact View.

Still can't reproduce here. Are you on jessie? hardware?

Eeqmcsq · 2017-09-23 01:13:51

Are you on jessie? hardware?

Yes, I'm using devuan jessie. I have only the MATE desktop installed, no XFCE or any other desktop.

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 1.0 (jessie)
Release:	1.0
Codename:	jessie

Based on what I've seen in the code, I don't think hardware matters. But in case it somehow does, it's a PC that I built a while back:

CPU: Athlon II X4 620e
Motherboard: Jetway NC84E-LF
RAM: 4 GB

I have no explanation why caja doesn't crash for you. From what I've seen in the code so far, caja must crash when in list view, if the split pane has been opened and closed, and you launch the File Management Preferences dialog.

- When you launch the File Management Preferences dialog, the code initializes the GUI in the "List Columns" tab.
- The act of initializing this GUI causes settings to be saved to "org.mate.caja.list-view". You can view these settings using dconf-editor.
- Whenever the settings for "org.mate.caja.list-view" are changed, each tab in the main pane or the split pane is called back, so the tab can add or remove columns or change the order to match the new settings.

- Caja creates a list view memory object for each tab that you open.
- When you close each tab, caja properly deletes the list view memory object from memory.
- But when you close the split pane, caja does NOT delete the list view memory object - it remains in memory!
- So when the "org.mate.caja.list-view" settings are changed, the list view memory object representing the closed split pane is still called back! Some of its data contents are now NULL, and when the code tries to use this NULL data, caja crashes.

If I can figure out why the split pane's list view memory object isn't properly deleted from memory when the split pane is closed, I think that will fix the crash, and possibly fix a memory leak as well.

greenjeans · 2017-09-24 20:06:45

Now I got it to reproduce, my bad, I assumed you meant adding/subtracting a tab vs. a pane , it does it here too.

Got a dollar says this has been around for years, more bad gnome code that never got fixed. Redundant in the first place, really no difference between running 2 panes and two tabs.

Really disappointed that Mate never fixed any of this stuff at least by the version we're using in jessie (1.8.2), I thought that was part of the point of Mate in the first place.

Stuff like this is why i'm pretty much done with Mate unless subsequent versions address some of this. I completely expect the refusal to acknowledge (much less fix) bugs mentality from the goobers that brought us dconf (the systemd of configuration) , I had hoped for better from Mate.

Thanks for posting this bug, it's small but needs to be dealt with, not swept under the rug.

Eeqmcsq · 2017-09-26 10:18:12

I've found the cause of the memory leak of the list view object which leads to the crash. This memory leak has been around since Nautilus 2.30.1 (Ubuntu 10.04). Also, I looked at the caja source code on github (1.19.1), and I think the memory leak is still there.

The memory leak fix is pretty simple, and I'd like to submit a patch to it for Devuan Jessie. How do I do that?

Really disappointed that Mate never fixed any of this stuff at least by the version we're using in jessie (1.8.2), I thought that was part of the point of Mate in the first place.

To be fair, the leak is pretty small and only occurs when the user opens and closes the split pane. The callbacks that eventually lead to the crash looks correct to me. The list view object remaining in memory after the split pane is closed is what should NOT be happening.

It's possible that no one figured out that the crash is triggered by both the split pane and Preferences dialog. You can open and close the split pane, do a bunch of other stuff for a few hours, then open the Preferences dialog, and crash.

The officially official Devuan Forum!

#1 2017-09-20 09:31:21

Compiling, debugging: How do I know what compile settings devuan uses?

#2 2017-09-20 13:58:04

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#3 2017-09-20 20:45:32

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#4 2017-09-20 22:52:46

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#5 2017-09-20 23:00:31

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#6 2017-09-21 19:40:36

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#7 2017-09-21 21:03:13

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#8 2017-09-21 21:30:08

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#9 2017-09-22 20:44:14

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#10 2017-09-23 01:13:51

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#11 2017-09-24 20:06:45

Re: Compiling, debugging: How do I know what compile settings devuan uses?

#12 2017-09-26 10:18:12

Re: Compiling, debugging: How do I know what compile settings devuan uses?

Board footer