WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 36118
[Qt] QtLauncher is breaking when loading any URL
https://bugs.webkit.org/show_bug.cgi?id=36118
Summary
[Qt] QtLauncher is breaking when loading any URL
Jesus Sanchez-Palencia
Reported
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().
Attachments
Add attachment
proposed patch, testcase, etc.
Fridrich Strba
Comment 1
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?
Jesus Sanchez-Palencia
Comment 2
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?
Fridrich Strba
Comment 3
2010-03-15 12:33:21 PDT
Could you just roll it back locally to see whether it really fixes your issue?
Eric Seidel (no email)
Comment 4
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?
Gustavo Noronha (kov)
Comment 5
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?
Jesus Sanchez-Palencia
Comment 6
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.
Fridrich Strba
Comment 7
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.
Gustavo Noronha (kov)
Comment 8
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.
Jesus Sanchez-Palencia
Comment 9
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.
Andras Becsi
Comment 10
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?
Kent Hansen
Comment 11
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?).
Fridrich Strba
Comment 12
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 :)
Yael
Comment 13
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.
Diego Gonzalez
Comment 14
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.
Jesus Sanchez-Palencia
Comment 15
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?
Kent Hansen
Comment 16
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.
Simon Hausmann
Comment 17
2010-03-16 08:41:20 PDT
Rolled out offending patch in
http://trac.webkit.org/changeset/56062
and re-opened
bug #34888
Kent Hansen
Comment 18
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!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug