Bug 36118

Summary: [Qt] QtLauncher is breaking when loading any URL
Product: WebKit Reporter: Jesus Sanchez-Palencia <jesus>
Component: WebKit QtAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Major CC: abecsi, diegohcg, eric, gns, hausmann, kent.hansen, oliver, ossy, vestbo, yael
Priority: P2 Keywords: Qt
Version: 528+ (Nightly build)   
Hardware: All   
OS: OS X 10.5   

Description Jesus Sanchez-Palencia 2010-03-15 08:12:39 PDT
After "Allow building smoothly on win32 and win64 using GCC" (a53cb1ab72845c90b29016afbd0eb098d14ea857) QtLauncher can't open any URL.
The backtrace is here: http://pastebin.ca/1841212

This has been verified on Linux and Mac OS, with WebKit trunk (HEAD c86e619be19285f136af4b60cadca97c9283499b) and Qt 4.7 (HEAD a0bcfa560dbc0ad98f8eeb821fe4dd84da207985).

As you can see on the backtrace, something seems to be wrong in JSC::Heap::allocateBlock().
Comment 1 Fridrich Strba 2010-03-15 08:27:45 PDT
I am just wondering what this patch which went in could affect for mac? https://bug-35607-attachments.webkit.org/attachment.cgi?id=49852
I would check maybe something else?
Comment 2 Jesus Sanchez-Palencia 2010-03-15 12:28:38 PDT
Eric, how do we normally deal with an issue like this?

Should we roll out the patch until it is fixed?
Comment 3 Fridrich Strba 2010-03-15 12:33:21 PDT
Could you just roll it back locally to see whether it really fixes your issue?
Comment 4 Eric Seidel (no email) 2010-03-15 12:36:47 PDT
This bug is very unclear.

What commit caused the regression?  Please provide the trac.webkit.org url.
Can you also provide a url to exhibited bot failures?
Comment 5 Gustavo Noronha (kov) 2010-03-15 12:40:28 PDT
(In reply to comment #0)
> After "Allow building smoothly on win32 and win64 using GCC"
> (a53cb1ab72845c90b29016afbd0eb098d14ea857) QtLauncher can't open any URL.
> The backtrace is here: http://pastebin.ca/1841212

Did you bisect that? Why does the failure not show up on the buildbot?
Comment 6 Jesus Sanchez-Palencia 2010-03-15 12:55:15 PDT
(In reply to comment #5)

> Did you bisect that? Why does the failure not show up on the buildbot?

Maybe because we don't have buildbot for Qt on Mac... I'm re-checking this, rolling out the patch locally and then I'll comment here the results.

But what I did was to reset my working tree to a point exactly before that commit and everything worked just fine.
Comment 7 Fridrich Strba 2010-03-15 12:57:48 PDT
That patch went in on 2nd of March, so what you now know that something in the last 2 weeks broke your build. If you read the patch you will understand that it was not it.
Comment 8 Gustavo Noronha (kov) 2010-03-15 13:02:31 PDT
Plus, you say it's been verified in both Mac, and Linux. The bot runs Linux, why didn't it fail? It would be better if you could bisect it.
Comment 9 Jesus Sanchez-Palencia 2010-03-15 19:03:37 PDT
(In reply to comment #7)
> That patch went in on 2nd of March, so what you now know that something in the
> last 2 weeks broke your build. If you read the patch you will understand that
> it was not it.

You are right. Me and a fellow co-worker were on such a rush over the weekend that we just took a quick a look at the backtrace, found the last patch dealing with that function and reset our tree to that point. We did this and I opened the bug without any further investigation... sorry, my bad. Right now I'm not sure what triggers the bug, but I'm looking for it.


(In reply to comment #8)
> Plus, you say it's been verified in both Mac, and Linux. The bot runs Linux,
> why didn't it fail? It would be better if you could bisect it.

Yes, two co-workers verified this on Linux and one other verified this on Mac (besides me). Don't know why the bot didn't catch it, but I'm already "bitsecing" on Mac and another guy is "bitsecing" on Linux.

It is taking a while, but we will find it. ;)

Sorry for any inconvenience. I'll let you know when we make any advances on this.
Comment 10 Andras Becsi 2010-03-16 03:35:04 PDT
> (In reply to comment #8)
> > Plus, you say it's been verified in both Mac, and Linux. The bot runs Linux,
> > why didn't it fail? It would be better if you could bisect it.

The buildbot only runs DRT, if the bug is related to QtLauncher not the platform independent part then the bot won't report any issues.

> Yes, two co-workers verified this on Linux and one other verified this on Mac
> (besides me). Don't know why the bot didn't catch it, but I'm already
> "bitsecing" on Mac and another guy is "bitsecing" on Linux.
> 
> It is taking a while, but we will find it. ;)
> 
> Sorry for any inconvenience. I'll let you know when we make any advances on
> this.

Could you specify, how the bug can be reproduced on Linux, because I just build a release version of trunk, and QtLauncher works perfectly on the buildbot environment. Was it a release or a debug wersion where the problem occured?
Btw, I used Qt 4.6.2, so maybe the problem is caused by some older Qt version?
Comment 11 Kent Hansen 2010-03-16 03:46:43 PDT
Oops, I think I broke the Mac with the patch for https://bugs.webkit.org/show_bug.cgi?id=34888; please roll out r55889.

It looks like we are targeting Tiger (i.e. TARGETING_TIGER will be defined) even when building on Leopard and above. This means it's going to use the vm_map tags that work with Tiger, but unfortunately they _don't_ work with Leopard (and vice versa). But not crashing on Leopard (and crashing on Tiger) when you built it on Leopard is better than it not crashing on Tiger, I guess. ;D

The way it is now (or with the patch rolled out, that is), I think there should be a configure/compile-time failure when this is detected, since we claim to target Tiger but the binary is going to crash on Tiger. Or, we bump the default macosx-version-min-required to 10.5 so that it will work for us (but one can still override it one needs to target 10.4, which some of our customers still do).

I'll also investigate whether there is a set of tags that work on both 10.4 and 10.5, even if that means disabling the features that the tagging provides (AFAIK it's only for debugging/profiling?).
Comment 12 Fridrich Strba 2010-03-16 04:49:14 PDT
OK, it looks like my patch is safe now and nobody feels like reverting it, so removing myself from CC :)
Comment 13 Yael 2010-03-16 07:22:55 PDT
(In reply to comment #11)
> Oops, I think I broke the Mac with the patch for
> https://bugs.webkit.org/show_bug.cgi?id=34888; please roll out r55889.

I have confirmed on my mac that rolling out this task fixes the problem.
Comment 14 Diego Gonzalez 2010-03-16 07:30:31 PDT
I got the crash on LINUX with hash b925242be2bccdb25078be49dfcd85b820f25353
or r55878. But with the current trunk it's no crashing anymore.
Comment 15 Jesus Sanchez-Palencia 2010-03-16 08:23:33 PDT
(In reply to comment #13)
> (In reply to comment #11)
> > Oops, I think I broke the Mac with the patch for
> > https://bugs.webkit.org/show_bug.cgi?id=34888; please roll out r55889.
> 
> I have confirmed on my mac that rolling out this task fixes the problem.

Me (and git bisect ;) too. Kent, how can we fix this?
Comment 16 Kent Hansen 2010-03-16 08:40:45 PDT
(In reply to comment #15)
> (In reply to comment #13)
> > (In reply to comment #11)
> > > Oops, I think I broke the Mac with the patch for
> > > https://bugs.webkit.org/show_bug.cgi?id=34888; please roll out r55889.
> > 
> > I have confirmed on my mac that rolling out this task fixes the problem.
> 
> Me (and git bisect ;) too. Kent, how can we fix this?

Simon is rolling out the change so we will be back to Leopard working again but Tiger crashing, I need more time to test different approaches.
Comment 17 Simon Hausmann 2010-03-16 08:41:20 PDT
Rolled out offending patch in http://trac.webkit.org/changeset/56062 and
re-opened bug #34888
Comment 18 Kent Hansen 2010-03-16 08:59:15 PDT
(In reply to comment #17)
> Rolled out offending patch in http://trac.webkit.org/changeset/56062 and
> re-opened bug #34888

Thanks Simon, and I'm really sorry you other guys had to spend time chasing this!