Crashing when switching to main frame

[waltercacau]

walterca...@gmail.com commented:

Which version of PhantomJS are you using? Tip: run 'phantomjs --version'.
1.8.1

What steps will reproduce the problem?
The crash is non deterministic. I am still trying to create a simple test case that reproduces the problem more frequently, but the main steps are:

1. You need to have nested frames (in my case I had a MAIN PAGE -> FRAME A -> FRAME B -> FRAME C)
2. You should switch to FRAME C by calling switchToFrame appropriately.
3. One of the inner frames changes its url (probably through javascript). In my case it should be FRAME A changing.
4. You should try switching to the main frame calling switchToMainFrame
5. phantomjs crashes

What is the expected output? What do you see instead?
Not crashing, but it does.

Which operating system are you using?
Mac OS X Lion

Did you use binary PhantomJS or did you compile it from source?
binary (installed using Homebrew)

Please provide any additional information below.

I gave a try in finding what was causing the issue and produced the attached stacktrace using the wiki instructions. The most relevant part seemed to be the following:

Thread 0 (crashed)
0 phantomjs!__ZNK3WTF6Stringcv7QStringEv + 0xd
eip = 0x000dae7d esp = 0xbfffdc80 ebp = 0xbfffdc98 ebx = 0xbfffdcfc
esi = 0xbfffdcfc edi = 0x0507a840 eax = 0x24ff003e ecx = 0x00000000
edx = 0x029b52a0 efl = 0x00210282
Found by: given as instruction pointer in context
1 phantomjs!__ZNK9QWebFrame9frameNameEv + 0x21
eip = 0x0103fad2 esp = 0xbfffdca0 ebp = 0xbfffdcb8
Found by: previous frame's frame pointer
2 phantomjs!__ZN7WebPage18changeCurrentFrameEP9QWebFrame + 0x4d
eip = 0x00056d5e esp = 0xbfffdcc0 ebp = 0xbfffdd18
Found by: previous frame's frame pointer
3 0x50755bf
eip = 0x050755c0 esp = 0xbfffdcfc ebp = 0xbfffdd18 ebx = 0x0297ae00
esi = 0xbfffdd18 edi = 0x00056d5e
Found by: call frame info
4 phantomjs!__ZN7WebPage17switchToMainFrameEv + 0x1c
eip = 0x0005731d esp = 0xbfffdd20 ebp = 0xbfffdd38
Found by: previous frame's frame pointer

Then, I found in webpage.cpp the following function indicated by the stacktrace:

void WebPage::changeCurrentFrame(QWebFrame * const frame)
{
if (frame != m_currentFrame) {
qDebug() << "WebPage - changeCurrentFrame" << "from" << m_currentFrame->frameName() << "to" << frame->frameName();
m_currentFrame = frame;
}
}

My guess is that m_currentFrame was freed and this debug line is causing the crash. So maybe its best to not call "m_currentFrame->frameName()", especially because it is just for logging.

Hope it helps you guys to solve the issue.

Thanks for the awesome open source project!

Best Regards,
Walter

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #1103.
🌟   3 people had starred this issue at the time of migration.

[vitallium]

vitaliy....@gmail.com commented:

 

 
Metadata Updates

• Merged into: Phantom 1.8.0 segfaults when appending and removing an iframe (YUITest) #10947 (GC-947)
• Status updated: Duplicate

[waltercacau]

walterca...@gmail.com commented:

Hi, just wanted to let you guys now that commenting the mentioned line did the tick. I compiled PhantomJS myself with the debug line commented and I don't see the crash anymore. I tested running my scripts almost 40 times and have not seen the crash again. Before, it would happen once every 4 times I ran.

This issue was marked as duplicate of 947, but I am not completely sure it should yet. Issue 947 seems to be related to accessing a frame when it was not yet properly bootstrapped by setupFrame. But the current issue seems to be more related with accessing a freed frame or a freed property of a frame, as the code indicates.

[vitallium]

vitaliy....@gmail.com commented:

Hi!

Issue 947 is exactly about invalid (freed) pointer to QWebFrame.
Could you provide a simple test case?

[vitallium]

vitaliy....@gmail.com commented:

 

 
Metadata Updates

• Status updated: NeedsReduction

[waltercacau]

walterca...@gmail.com commented:

Hi!

Sure, attached is one test case that shows the problem.
How to run:

1. Unzip
2. Run SimpleHTTPServer:
   python -m SimpleHTTPServer
3. Run in another terminal the following bash script:
   while [ 1 ]; do
   echo "Running ...";
   phantomjs crash.js | grep "PhantomJS has crashed";
   done

Leave it running for a while. In my machine the crash, running 48 times I got 8 crashes (about 16%)

Hope it helps

[waltercacau]

walterca...@gmail.com commented:

Has anyone been able to reproduce this?

[vitallium]

vitaliy....@gmail.com commented:

Almost. I tried this on Windows, and I was unable to reproduce this issue. Will try to repro this on my Ubuntu installation.

[vitallium]

Fixed in 1.9

[mandarille]

This issue still exist and hasn't been solved by the solution in 947. I can reproduce it - and it was solved by changing the qdebug line suggested in this thread.

The crash occurs when currentFrame disappears and the debug line tries to acces the frameName of a not existing frame.

In my case I have a popup with an iframe that disappears that triggers the crash. The fix should be easy - put in a check for null pointer.

[SteveHarris]

This is not fixed in 1.9.8

[lstreet-aquent]

It should be fixed by #12109 when it gets merged. I didn't hear back definitively about whether I should move the test cases and forgot about it.

[SteveHarris]

I cannot overstate the importance of getting this fixed and released. PhantomJS is incredibly valuable, but crashing on iframes makes it unusable. I see the null check is on 2.0, but not on 1.9 code base. I know the team is really focused on 2.0 release, but this is a critical patch.

[SteveHarris]

We are still getting crashes on frame switches in 2.0.0 as well. :-( This is terrible as we have to keep running resource heavy "Selenium" instead of PhantomJS.

[zackw]

For the record, there will be no further fixes to any 1.9 branch.

[zackw]

PR#12109 has been merged; the fix will be in the upcoming 2.1.