[Solved] Source increasingly out of date with execution

Development
1

Is there a cache for objects, images or debugging information?

What I’m seeing is that I rebuild my software and it runs some old version of it that is increasingly out of date with what the source says it should be doing. For instance I’ve removed a particular assert and yet it still keeps happening at runtime.

“But maybe your makefiles are using old objects?”

Yeah nah, I’ve triple checked that all the objects are removed by “make cleanall” and the newly built objects have the current time/date. And indeed the images in the debugger are the correct path, and there are no duplicates of the objects or source or binary images. I feel like I’m going mad here.

This seems to be a relatively new issue. As in everything was working great up until last week. And the haiku I’m running on hasn’t had any changes that I know of. I didn’t install anything or change anything at a system level that I know of.

The actual makefiles in question are:
https://phab.mallen.id.au/source/lgi/browse/default/Makefile.haiku
https://phab.mallen.id.au/source/lgi/browse/default/Ide/haiku/Makefile.haiku

And the specific assert I see at runtime is line 322 in:
https://phab.mallen.id.au/source/lgi/browse/default/include/lgi/common/Array.h

Which as you can see is:
a) commented out… and
b) now moved to line 331, not 322

Thoughts?

2

… I just ran into this exact situation a few days ago and also thought either something broke or I was also going mad.

I know you said you already checked this but in my case I had another copy of my repo that was off by one directory. I thought I had checked my paths in the debugger but I didn’t notice that the path was just one level different.

I’m sure that’s not your issue, but never hurts to do one more sanity check?

3

That’s what I thought too… would make total sense.

When I call “find” from my home folder to look for dupes I get:

~> find . -iname Array.h
./code/lgi/trunk/include/lgi/common/Array.h
~> find . -iname "XmlTree.*"
./code/lgi/trunk/Debug/XmlTree.o 
./code/lgi/trunk/Debug/src/common/Text/XmlTree.d
./code/lgi/trunk/include/lgi/common/XmlTree.h
./code/lgi/trunk/src/common/Text/XmlTree.cpp

Which seems to confirm I only have one copy of that source and object.

4

Check if there is a duplicate of your executable lying somewhere around and delete it.
Haiku uses mime-type to start the programs, this is why a duplicate causes issue like yours.

5

For things launched based on filetype or other places, yes. For things launched by directly running a command on the command line, no, it should start referenced program directly like any other OS, independent of mimetypes.

1 Like
6

Suggestion: Switch to -O0, step debug in the Debugger.

7

Yeah this is what it ended up being. I moved the makefile into a subfolder for that project and ended up with one executable in the main directory and one in the makefile subfolder. What was confusing me is that the Linux makefile builds the binary in the top level folder and I hadn’t rolled that change over to the Haiku makefile.

Duh.

Sometimes some good sleep and a fresh look at it does wonders.

3 Likes