trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] TIME Frame 3/29 -> 4/10 kwrite crash introduced

From: Darrell Anderson <humanreadable@...>
Date: Mon, 30 Apr 2012 21:25:19 -0700 (PDT)
> > The problem I see with kwrite is I can't scroll through
> to the end of a basic text file. The file I am using is 232
> lines long. Hardly a mammoth. Yet whether I scroll one line
> at a time with the Down arrow key, use Page Down, or use
> Ctrl-End, kwrite freezes and stops responding. At this point
> I'm not set up to do backtraces. I don't see any classic
> crash anyway. The app just freezes.
> > 
> > Curiously, kate does not do this. I tested kate with
> the Memory Usage buffer set at 16 and at 512 (maximum). No
> difference. Kate behaves for me.

I have been using the same profile and deleting the cache. For this kind of problem, I probably should create a fresh profile each time. Who knows how this bug is corrupting or influencing the config files.

Ignore my build reports from today. The git reset thing means my results are not trustworthy. Best start from scratch.

As you think the problem is between 3/29 and 4/10, start bisecting at 4/4. That's where I was when I quit.

Now here is the kicker I recognized on my third attempt today that broke my proverbial camel's back. Resetting to an earlier commit point means all those gcc 4.7 patches we pushed no longer are available. That means compiling will break --- and did for me.

I tried using -fpermissive. The packages built without incident, but when I tried to run them, all hell broke loose. I could not run apps from the mini cli and received messages the files did not exist. The  files did exist and $PATH was just fine.

At that point I quit.

In hindsight I do not like the idea of using -fpermissive for troubleshooting this problem. Doing so adds another variable to the problem. Specifically, what if the problem is gcc and not a patch? Then using -fpermissive masks the problem because gcc no longer is compiling according to the stricter standards. That would be significant time wasted, not to mention not finding the root cause of the problem.

You'll need to use a few patches as necessary to get past the build problems without -fpermissive. You'll need the easyvector patch, unless that part of the code is in a section that can be bypassed in the build configuration (-DBUILD_WHATEVER=OFF). I back ported that patch but then I encountered another build failure regarding dcop, which then prompted me to use -fpermissive. So at this point I know you'll need at least two of the patches we were using before they were pushed to git.

I have a lot of things outside the project suddenly pulling at me, which doesn't help and certainly added to today's stress. The ebb and flow of life. The best approach is to take care of those things. I don't expect to help for a few days but I'll keep tabs on the emails as best I can.

I'm sure this won't be the last time we need to reset the sources for debugging purposes. If you get through this ordeal without losing your mind then perhaps a short wiki how-to would be nice. :-)

Darrell