Skip to content
This repository has been archived by the owner on May 30, 2023. It is now read-only.

PhantomJs crashing after 42 Instances running 5 clients per Instance (240) - pure virtual method called #12309

Closed
weltonrussell opened this issue Jun 13, 2014 · 1 comment

Comments

@weltonrussell
Copy link

Hi,

I have tried running a modified version of phantomjs (disable caching each open) to simulate load testing on one of my servers. After running 42 Instances with 5 Clients per instance hitting about 240 - 260 clients it crashes saying pure virtual method called.

I have tried to debug using gdb after re-compiling using the command
./build.sh --qmake-args CONFIG+=debug

however once installed and using gdb I get the message
Reading symbols from /usr/bin/phantomjs...(no debugging symbols found)...done. And only get thread debugging.

I was wondering if anyone would know the root cause of these two problems

catharsis pushed a commit to catharsis/phantomjs that referenced this issue Jan 9, 2015
This patch works around/ameliorates around a bug in QT 4
(https://bugreports.qt.io/browse/QTBUG-29452) which triggers the
infamous "pure virtual method called" crash. In summary, the problem is
that threads that are supposed to handle HTTP requests are not
necessarily fully constructed when time comes to do the handling.

This patch is only applicable for phantomjs 1.9, since later releases
to my understanding will use QT 5, in which the bug has been properly
fixed.

This workaround does a very primitive usleep()-loop, continually
checking for thread->isRunning() to make sure that we actually are ready
to deal with the request.

NB. This is not a proper fix, since the race condition might in theory
still occur. However, after running this patch (with a sleep celiing of
0.1 seconds, as opposed to the full 1 second in this patch) internally
it has significantly reduced the occurence of the issue. It took me a
full day of re-building to trigger the error. Again, that was with the
0.1 seconds, this patch increases that number by a factor of 10.

It's worth noting that, unsuprisingly, the issue is easier to reproduce
with a system under heavy load, such as a build slave building a lot of
things in parallel.

Note also that the workaround suggested in the bug report to QT is not
feasible:
    ...
    manager->httpThread->start();
    manager->httpThread->wait(20); // add this line
    ...

Partially, because this workaround applied verbatim only affects
asynchronous requests but moreso because:

"[the QThread::wait() function] also returns true if the thread has not been started yet."

See http://qt-project.org/doc/qt-4.8/qthread.html#wait.

This fixes issues ariya#12325, ariya#11651, ariya#12006, ariya#11687, ariya#12816, ariya#11857,
 ariya#12054, ariya#11577, ariya#11597, ariya#12284

This probably/possibly (but can't verify because of missing stack
traces) fixes issues ariya#11047, ariya#11347, ariya#12026, ariya#12309, ariya#10666, ariya#11696, ariya#12133, ariya#10823,
 ariya#10717, ariya#12348

And probably others that I couldn't find or that have already been
closed.

Signed-off-by: Anton Lofgren <alofgren@op5.com>
@vitallium
Copy link
Collaborator

Please upgrade to PhantomJS 2. 1.9.x is no longer supported, and known to have many crasher bugs that are fixed in 2 version.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants