Instead of trying to use sourceId to determine what module threw an
error, we now load module's source code using modified
QWebFrame::evaluateJavaScript and leverage PhantomJS's stack traces.
http://code.google.com/p/phantomjs/issues/detail?id=47
Most of the tests passed after merging almost unchanged phantomjs-nodify
code, some needed small changes. The one that is still failing is for
CoffeeScript modules.
http://code.google.com/p/phantomjs/issues/detail?id=47
http://code.google.com/p/phantomjs/issues/detail?id=599
Squashed commit of the following:
commit 2cdcf8a47567f3c067958383843cccf858af531c
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:37:38 2012 +0100
Make lib-bundling/brandelf optional in deploy/package.sh
This configuration has had some problems and we don't wish to use it in
the official packages.
Enable it with --bundle-libs.
commit 2a2155a4e1f5873aa8624859cead9d66750747f4
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:24:40 2012 +0100
notify user if upx is missing
commit 9656a99df0ff101150276dc88e0127f68041f617
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:23:36 2012 +0100
stripping symbols after upx probably doesn't work, reorder that
commit c5f425dc17069c89e7d2ff274309006c728ffab4
Author: Jon Leighton <j@jonathanleighton.com>
Date: Sat Jul 7 19:17:07 2012 +0100
fix logical fail
For some reason, it seems that checking CONFIG(static) inside
src/phantomjs.pro is not reliable. That caused the STATIC_BUILD define
not to be set, and hence Q_INIT_RESOURCE would never get called in
main.cpp.
Instead of using Q_INIT_RESOURCE, let's just compile the resources
directly into the phantomjs binary. This means we don't need to detect
whether Qt is linked statically or dynamically.
https://code.google.com/p/phantomjs/issues/detail?id=430
We are linking against e.g. libQtCore.so.4 rather than
libQtCore.so.4.8.2, and this affects symbol generation. (I am not sure
if this changed at some point, but this change should make it generate
the correct symbol files regardless.)
Also makes it less dependent on the Qt version.
Debug mode turns off all optimisations. This make PhantomJS considerably
slower.
Instead, we build in 'release' mode, but generate debugging symbols at
the same time.
This may present some problems analysing crashes, if the optimisations
make that difficult. However, in my testing I was able to get useful
debug output even with optimisations enabled. So we should see how we go
- if it becomes a problem we can produce seperate debug binaries with no
optimisations.
https://code.google.com/p/phantomjs/issues/detail?id=599
This provides support for compiling the breakpad client into PhantomJS,
and generifies that Linux packaging scripts so that they also apply to
OS X and automate the symbol generation.
Building the Breakpad tool programs seems to be less than
straightforward on OS X, and documentation is poor. We have managed to
produce tools/dump-syms-mac.pro which allows building the dump_syms
program for dumping the debugging symbols. This needed a couple of
modifications to breakpad in order to compile successfully.
We have run out of time to work on making the minidump_stackwalk program
build. However, this is solely a developer tool and so it can wait until
after the 1.6 release before we complete this work.
Testing is welcome!
https://code.google.com/p/phantomjs/issues/detail?id=576
When console.error was called, there was a segfault because it was
treated as an uncaught exception, but did not have the correct stack
trace information (I am not sure why, but still...)
Now that we are generating the stackTrace in WebCore::reportException,
the MessageType gets set correctly, so we can use this to differentiate
between uncaught exceptions and other messages.
https://code.google.com/p/phantomjs/issues/detail?id=47
On reflection, this approach seems like a bad idea and a source of bugs.
I think passing object references between pages seems inherently
problematic, and we are better off just passing data to the onError
handler. If users need the actual object reference, they are able to use
try ... catch within the page.
This change also means that we are no longer breaking backwards
compatibility with the page.onError function signature.
WebCore already has a bunch of plumbing to pass around stacks. This
exists for the inspector/console. However, we need to actually retrieve
the error stack in WebCore::reportException.
To achieve this, I am attaching a stackArray property to the error
object. This is not as clean as I'd like, but seems ok for now. (We
should not document stackArray though.)
https://code.google.com/p/phantomjs/issues/detail?id=166
Juliusz Gonera