berkelium segfaults on RPi, while the build chrome works correctly about berkelium HOT 7 OPEN

Ok currently busy compiling a Debug version of Chromium and Berkelium. I hope to get a more useful error from berkelium with the Debug version. It will take another day or 2 before I can tell more.

from berkelium.

I don't have anyway to get more information. Before bothering with a Debug version, I'd try running it under a debugger to grab a stack trace -- it may be crashing in Berkelium, in which case you wouldn't need to spend two days building a debug version of Chromium. Berkelium can safely use Debug mode with a Release version of Chromium.

If you don't have a debugger, dig around in Chromium's settings a bit. They report crashes with a minidump format generated by Breakpad (http://code.google.com/p/google-breakpad/). I'm not sure those ever hit disk though, and I don't know that we actually initialize anything to do that for us in Chromum, but it might be worth a look. Also, it'd be good to know which process is crashing.

from berkelium.

Hi, sorry for the long delay but I was in the middle of building the debug version of chromium and berkelium. After one point failed I started it with the debugger so now I got the error message.

Program received signal SIGSEGV, Segmentation fault.
0x41f3e580 in emit_dqt () from /home/pi/raspberry/berkelium/liblibberkelium.so

So it indeed looks like it came from berkelium.

Update : It seems berkelium can't handle something libjpeg_turbo is pushing out. the function emit_dqt comes from this tool. Strange thing is that chrome self doesn't complain about this.

If I can get the whole debug version of berkelium linked I maybe can get you a stacktrace.

from berkelium.

Well, you need to look at the exact stack trace because we link chromium and all its libraries into libberkelium. This one looks like it's actually coming from libjpeg (see jcmarker.c). Not sure why it would be crashing there though. You might also try a few other pages, especially trivial test pages so you minimize the number of things that can go wrong (e.g. no CSS files, no images, etc).

from berkelium.

Backtrace :

#0 0x41f3e580 in emit_dqt () from /home/pi/raspberry/berkelium/liblibberkelium.so
#1 0x41f3e89c in write_frame_header () from /home/pi/raspberry/berkelium/liblibberkelium.so
#2 0x41f3f368 in pass_startup () from /home/pi/raspberry/berkelium/liblibberkelium.so
#3 0x41f3df88 in chromium_jpeg_write_scanlines () from /home/pi/raspberry/berkelium/liblibberkelium.so
#4 0x42018378 in gfx::JPEGCodec::Encode(unsigned char const_, gfx::JPEGCodec::ColorFormat, int, int, int, int, std::vector<unsigned char, std::allocator >) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#5 0x404a4e9c in history::TopSites::EncodeBitmap(SkBitmap const&, scoped_refptr) ()
from /home/pi/raspberry/berkelium/liblibberkelium.so
#6 0x404a4f9c in history::TopSites::SetPageThumbnail(GURL const&, SkBitmap const&, ThumbnailScore const&) ()
from /home/pi/raspberry/berkelium/liblibberkelium.so
#7 0x416ce704 in RenderViewHost::OnMsgThumbnail(GURL const&, ThumbnailScore const&, SkBitmap const&) ()
from /home/pi/raspberry/berkelium/liblibberkelium.so
#8 0x416d6968 in RenderViewHost::OnMessageReceived(IPC::Message const&) clone .part.167
from /home/pi/raspberry/berkelium/liblibberkelium.so
#9 0x408cb7d8 in BrowserRenderProcessHost::OnMessageReceived(IPC::Message const&) clone .part.131
from /home/pi/raspberry/berkelium/liblibberkelium.so
#10 0x4159ee0c in IPC::ChannelProxy::Context::OnDispatchMessage(IPC::Message const&) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#11 0x4159ecbc in RunnableMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::)(IPC::Message const&), Tuple1IPC::Message >::Run() () from /home/pi/raspberry/berkelium/liblibberkelium.so
#12 0x40c14348 in MessageLoop::RunTask(Task) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#13 0x40c16bd0 in MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#14 0x40c16dec in MessageLoop::DoWork() () from /home/pi/raspberry/berkelium/liblibberkelium.so
#15 0x40c4fe04 in base::MessagePumpForUI::RunWithDispatcher(base::MessagePump::Delegate_, base::MessagePumpForUI::Dispatcher_) ()
from /home/pi/raspberry/berkelium/liblibberkelium.so
#16 0x40c4fe98 in base::MessagePumpForUI::Run(base::MessagePump::Delegate_) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#17 0x40c16090 in MessageLoop::RunInternal() () from /home/pi/raspberry/berkelium/liblibberkelium.so
#18 0x40c16174 in MessageLoopForUI::Run(base::MessagePumpForUI::Dispatcher*) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#19 0x403ddfa0 in BrowserMain(MainFunctionParams const&) () from /home/pi/raspberry/berkelium/liblibberkelium.so
#20 0x40304914 in Berkelium::forkedProcessHook (argc=0, argv=0x0) at /home/pi/raspberry/berkelium/src/ForkedProcessHook.cpp:976
#21 0x000086ac in main ()

from berkelium.

Ewen, do you need more information about this problem to diagnose? I have tried to build a berkelium debug version but it locked up, so I first spent time getting Xibo up and running. The segfaults are still there but browsernode seem to work anyway. but to prevent it from breaking libavg when running long times it would in a digital signage project.

with regards,
Hellbender

from berkelium.

As I said before, there's not much I can do directly since I don't have this platform and, honestly, don't have the time to wait around for 2 day long builds. If you can get this stack trace info out, I'd guess you could grab some other info too, like what address/variable is actually causing the crash. Possibly if you report enough info here we could debug it, but it's in a third party library that's part of chromium, which is used by Berkelium -- we're multiple levels away from this actually being a Berkelium bug unless we can identify some failure to initialize Chromium/libjpeg properly.

I'm also somewhat suspicious that this is related to the changes you made to resolve #24 since it's occurring in libjpeg. Are you sure the version of libjpeg-turbo you grabbed is good? First, going from 75235 to 177737 sounds like a pretty big leap. Combining very new code with relatively old Chromium code doesn't always work out well. Sometimes looking for differences in Chromium in the surrounding code between now and Chromium11 can reveal some of these issues, e.g. look for differences in gfx::JPEGCodec. Second, do you know that that particular version is even a good, stable version? Is it used in one of the Chrome releases?

One last idea is just a simple work around. The stack trace shows this as having something to do with saving thumbnails for pages for the history, presumably what's shown in the UI for previous pages you've viewed. You might be able to just patch it to always return an error for that message instead, which presumably has no effect on you since this is never displayed in Berkelium. Alternatively, try to figure out why emit_dqt is failing to properly call back to the JPEGCodec code (or if it's failing internally accessing its own buffers).

from berkelium.