Bug 2116

Add Konqueror to the list of apps that crashes.

(In reply to Michele Calgaro from comment #1)
> Add Konqueror to the list of apps that crashes.

Well this isn't good--this exact crash popped up once on the mailing list a little while ago, and I didn't have a solution for it.  Looks like I now have no choice but to debug on Debian Testing.

Tim

> Well this isn't good--this exact crash popped up once on the mailing list a
> little while ago
I think that was my first encounter of the Amarok crash, a few weeks ago :)

I will also work on this bug as soon as I have some time (unfortunately until the end of September I am pretty busy and have little time for TDE). The bug is quite important because it affects several applications, so I think it is not a bad idea if we both work on that until one of us find a solution.

The easiest way to reproduce the bug is this:
1) install a base Debian/Testing system on a VM, no DE
2) install TDE (at least up to tdebase, plus amarok and tdelibs debug symbols)
3) run amarok, go through the wizard the first time it is run, then run amarok and you get the crash described.

If you need info on how to crash TDevelop or Konqueror let me know.

Tim,
I have looked into this bug for a couple of hours today.
Sharing what I have found so far, the crash happens in UString::Rep::destroy() in tdelibs/kjs/ustring.cpp 

void UString::Rep::destroy()
{
  if (capacity == capacityForIdentifier)
    Identifier::remove(this);
  delete [] dat;
  delete this;
}

at the "delete this" line. The crash happens when the static Rep objects ("null" or "empty") are invoked for destruction, since those two objects are not allocated dynamically. This should not happen normally if the reference count is always correct.
With a quick dirty patch (initializing those element ref counts to 1000 instead of 1) in the same file I can get Amarok to work properly.  

UString::Rep UString::Rep::null = { 0, 0, 0, 1000, 1 };
UString::Rep UString::Rep::empty = { 0, 0, 0, 1000, 1 };

Nevertheless TDevelop and Konqueror still crash, but now in a different way.
To crash Konqueror without going too far, just visit http://bugs.pearsoncomputing.net/
and then click on the "Search" link (or any other, they seem to have the same effect).

I thought the problem is caused by some specific Javascript code that makes KJS Collector go funny and mess up with the way it handles them, but visiting the clicked web pages directly
(for example http://bugs.pearsoncomputing.net/query.cgi)
does not crash Konqueror.
More analysis will be needed on this bug.

Whoever make progress on debugging this, please post your partial results on this bug report, so we don't waste time looking at the same thing twice.

Created attachment 2250 [details]
Fix accidental double-free in KJS garbage collector

I've been working on this as well, starting from crash report TDECRSH-e00e7df-06c0a25-f3f4e4f-81a0334-12f6a6e-2f7d9ec-bc79c78

From what I can tell there is an accidental double free occurring in the garbage collector.  The attached patch fixes the problem for me; can you test and verify that this works on your system?  Also appreciated would be a second pair of eyes to verify that this patch does not introduce some other problem in the KJS engine.

My best guess on the origins of this bug: the invalid memory access was likely present for a long time in TDE, but earlier versions of Debian and Ubuntu ignored the double free, whereas Jessie sends SIGABRT to the process upon noticing the double-free, making this problem user-visible for the first time.

Thanks!

Tim

Comment on attachment 2250 [details]
Fix accidental double-free in KJS garbage collector

I will give it a try and report back later

Tested. With the patch installed, Amarok, Konqueror and TDevelop do not crash anymore. You can proceed to push IMO. 
Well done and thanks Tim!!.

> My best guess on the origins of this bug: the invalid memory access was likely > present for a long time in TDE, but earlier versions of Debian and Ubuntu
> ignored the double free, whereas Jessie sends SIGABRT to the process upon 
> noticing the double-free, making this problem user-visible for the first time.

Perhaps, but it surprises my that SIGABRT was never raised until a month ago or so. I can easily google post about SIGABRT raised by deleting invalid pointer from 2007. I agree that probably the bug was there since a long time ago. Perhaps a change in a library has modified the sequence of some operations, resulting in additional releases of the "null"/"empty" Rep elements, which in turn highlighted the problem.
Anyhow, whatever is was, well done in fix it so quickly!

Comment on attachment 2250 [details]
Fix accidental double-free in KJS garbage collector

Pushed to GIT in hash 36a7df3.

Thanks for reporting and verifying!

Tim