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().
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?
Eric, how do we normally deal with an issue like this? Should we roll out the patch until it is fixed?
Could you just roll it back locally to see whether it really fixes your issue?
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?
(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?
(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.
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.
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.
(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.
> (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?
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?).
OK, it looks like my patch is safe now and nobody feels like reverting it, so removing myself from CC :)
(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.
I got the crash on LINUX with hash b925242be2bccdb25078be49dfcd85b820f25353 or r55878. But with the current trunk it's no crashing anymore.
(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?
(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.
Rolled out offending patch in http://trac.webkit.org/changeset/56062 and re-opened bug #34888
(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!