Gonk startup sometimes crashes after E/FramebufferNativeWindow(28557): couldn't open framebuffer HAL (No such file or directory)

RESOLVED FIXED in mozilla18


7 years ago
3 months ago


(Reporter: kanru, Assigned: cjones)


({crash, dogfood})

crash, dogfood

Firefox Tracking Flags



(crash signature)


(1 attachment)



7 years ago
Program received signal SIGSEGV, Segmentation fault.
    0x4129f4ee in ColorDepth () at /home/kanru/zone2/mozilla/central/widget/gonk/nsWindow.cpp:658
    658         switch (NativeWindow()->getDevice()->format) {
    (gdb) bt
    #0  0x4129f4ee in ColorDepth () at /home/kanru/zone2/mozilla/central/widget/gonk/nsWindow.cpp:658
    #1  0x4129f51e in nsScreenGonk::GetPixelDepth (this=0xa45f50, aPixelDepth=0xa4518c) at /home/kanru/zone2/mozilla/central/widget/gonk/nsWindow.cpp:672
    #2  0x4129f54e in nsScreenGonk::GetColorDepth (this=0xa45f50, aColorDepth=0xa4518c) at /home/kanru/zone2/mozilla/central/widget/gonk/nsWindow.cpp:679
    #3  0x41647fb4 in gfxAndroidPlatform (this=0xa45150) at /home/kanru/zone2/mozilla/central/gfx/thebes/gfxAndroidPlatform.cpp:34
    #4  0x41638dca in gfxPlatform::Init () at /home/kanru/zone2/mozilla/central/gfx/thebes/gfxPlatform.cpp:299
    #5  0x41638c06 in gfxPlatform::GetPlatform () at /home/kanru/zone2/mozilla/central/gfx/thebes/gfxPlatform.cpp:236
    #6  0x40a5057e in mozilla::dom::AzureCanvasEnabled () at /home/kanru/zone2/mozilla/central/content/canvas/src/nsCanvasRenderingContext2DAzure.cpp:556
    #7  0x40c769a0 in nsDOMClassInfo::Init () at /home/kanru/zone2/mozilla/central/dom/base/nsDOMClassInfo.cpp:4537
    #8  0x40c77472 in NS_GetDOMClassInfoInstance (aID=eDOMClassInfo_IDBFactory_id) at /home/kanru/zone2/mozilla/central/dom/base/nsDOMClassInfo.cpp:5106
    #9  0x40d15192 in mozilla::dom::indexedDB::IDBFactory::QueryInterface (this=0xa44370, aIID=..., aInstancePtr=0xbeb2b384)
        at /home/kanru/zone2/mozilla/central/dom/indexedDB/IDBFactory.cpp:476
    #10 0x4153c498 in nsQueryInterface::operator() (this=0xbeb2b378, aIID=..., answer=0xbeb2b384)
        at /home/kanru/zone2/mozilla/B2G/objdir-gecko-debug/xpcom/build/nsCOMPtr.cpp:14
    #11 0x4153c526 in nsCOMPtr_base::assign_from_qi (this=0xbeb2b6f0, qi=..., iid=...)
        at /home/kanru/zone2/mozilla/B2G/objdir-gecko-debug/xpcom/build/nsCOMPtr.cpp:56
    #12 0x40fdbb4a in nsCOMPtr<nsIClassInfo>::operator= (this=0xbeb2b6f0, rhs=...) at ../../../dist/include/nsCOMPtr.h:640
    #13 0x40fd42be in xpcObjectHelper::GetClassInfo (this=0xbeb2b6e0) at /home/kanru/zone2/mozilla/central/js/xpconnect/src/xpcObjectHelper.h:71
    #14 0x40fd5814 in XPCWrappedNative::GetNewOrUsed (ccx=..., helper=..., Scope=0xa3c410, Interface=0x0, resultWrapper=0xbeb2b5b4)
        at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCWrappedNative.cpp:496
    #15 0x40fb5bc0 in XPCConvert::NativeInterface2JSObject (lccx=..., d=0xbeb2b8d0, dest=0x0, aHelper=..., iid=0x0, Interface=0x0,
        allowNativeWrapper=false, pErr=0xbeb2b6fc) at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCConvert.cpp:957
    #16 0x40f9f920 in NativeInterface2JSObject (lccx=..., aScope=0x442a8040, aCOMObj=0xa44370, aCache=0x0, aIID=0x0, aAllowWrapping=false,
        aVal=0xbeb2b8d0, aHolder=0x0) at /home/kanru/zone2/mozilla/central/js/xpconnect/src/nsXPConnect.cpp:1277
    #17 0x40f9faac in nsXPConnect::WrapNativeToJSVal (this=0x7804e0, aJSContext=0x7ae460, aScope=0x442a8040, aCOMObj=0xa44370, aCache=0x0, aIID=0x0,
        aAllowWrapping=false, aVal=0xbeb2b8d0, aHolder=0x0) at /home/kanru/zone2/mozilla/central/js/xpconnect/src/nsXPConnect.cpp:1334
    #18 0x40988c40 in nsContentUtils::WrapNative (cx=0x7ae460, scope=0x442a8040, native=0xa44370, cache=0x0, aIID=0x0, vp=0xbeb2b8d0, aHolder=0x0,
        aAllowWrapping=false) at /home/kanru/zone2/mozilla/central/content/base/src/nsContentUtils.cpp:6029
    #19 0x40a12856 in nsContentUtils::WrapNative (cx=0x7ae460, scope=0x442a8040, native=0xa44370, vp=0xbeb2b8d0, aHolder=0x0, aAllowWrapping=false)
        at ../../../dist/include/nsContentUtils.h:1726
    #20 0x40d3467c in mozilla::dom::indexedDB::IndexedDatabaseManager::InitWindowless (this=0xa3f5e8, aObj=..., aCx=0x7ae460)
        at /home/kanru/zone2/mozilla/central/dom/indexedDB/IndexedDatabaseManager.cpp:1914
    #21 0x41599390 in NS_InvokeByIndex_P (that=0xa3f5e8, methodIndex=<value optimized out>, paramCount=<value optimized out>,
        params=<value optimized out>) at /home/kanru/zone2/mozilla/central/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:160
    #22 0x40fda48a in CallMethodHelper::Invoke (ccx=..., mode=XPCWrappedNative::CALL_METHOD)
        at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCWrappedNative.cpp:3082
    #23 CallMethodHelper::Call (ccx=..., mode=XPCWrappedNative::CALL_METHOD)
        at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCWrappedNative.cpp:2416
    #24 XPCWrappedNative::CallMethod (ccx=..., mode=XPCWrappedNative::CALL_METHOD)
        at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCWrappedNative.cpp:2382
    #25 0x40fe2970 in XPC_WN_CallMethod (cx=0x7ae460, argc=1, vp=0x4354c1b8)
    ---Type <return> to continue, or q <return> to quit---q
     at /home/kanru/zone2/mozilla/central/js/xpconnect/src/XPCWrappedNativeJSOps.cpQuit
    (gdb) l
    653     }
    655     static uint32_t
    656     ColorDepth()
    657     {
    658         switch (NativeWindow()->getDevice()->format) {
    659         case GGL_PIXEL_FORMAT_RGB_565:
    660             return 16;
    661         case GGL_PIXEL_FORMAT_RGBA_8888:
    662             return 32;
    (gdb) p NativeWindow()
    $1 = (class android::FramebufferNativeWindow *) 0xa45f68
    (gdb) p NativeWindow()->getDevice()
    $2 = (const framebuffer_device_t *) 0x0

Comment 1

7 years ago
Tested on Otoro, not always reproduce able.

  adb reboot
  restart b2g a couple of times


7 years ago
Crash Signature: [@ ColorDepth]
Keywords: crash
I encountered this, too. From logcat it's ENOENT, but actually it's EPERM in opening /dev/graphics/fb0.

(in mapFrameBufferLocked() in framebuffer.cpp)
(gdb) p name
$20 = "/dev/graphics/fb0\000\004@P3\227A\351\255VA\263\000\000\000T\025\b@\320Ź\001\000\000\000\000\000\000\000\000T\025\b@ v\244\001\065\337\004@d\207ܾ"
(gdb) p __errno()
$21 = (volatile int *) 0x400885ac
(gdb) p *__errno()
$22 = 1 

mapFrameBufferLocked() in libgralloc/framebuffer.cpp tries to open /dev/graphics/fb* and then /dev/fb*. On otoro /dev/graphics/fb0 fails to open, so it then tries to open /dev/fb0, which doesn't exist. Even I chmod 666 /dev/graphics/fb0 it still crashes, but I don't know why.


7 years ago
Duplicate of this bug: 780709


7 years ago
blocking-basecamp: --- → ?

Comment 4

7 years ago
Kanru, can you check if this is still an issue with the new kernel update?

Comment 5

7 years ago
(In reply to Michael Wu [:mwu] from comment #4)
> Kanru, can you check if this is still an issue with the new kernel update?

After I flashed the new kernel update this issue seems to have gone away. I restarted b2g process 10 times without problem.

Comment 6

7 years ago
Cervantes also reports that new kernel fixed the issue. Close it.
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 7

7 years ago
I saw this again today, perhaps I was just lucky..
Resolution: WORKSFORME → ---
Could this affect gecko updates?
blocking-basecamp: ? → -

Comment 9

7 years ago
This happens quite often. I'm going to investigate into it.
Assignee: nobody → kchen
blocking-basecamp: - → ?

Comment 10

7 years ago
While trying to initialized framebuffer from b2g, we can't open fb0:

  /dev/graphics/fb0: Operation not permitted

Looks like a driver bug or b2g didn't teardown framebuffer cleanly puts graphic driver into a invalid state.
Is this still being seen during normal use of the phone? I still see it, but only when I'm using the debugger and the b2g process gets killed through the debugger (perhaps kill -9 would do the same thing)

Comment 12

7 years ago
In normal use of the phone this would only happen if the b2g process is killed by OOM killer (SIGKILL) or crashed itself. Maybe it will also happen when we apply update? I don't know how to test that.
blocking-basecamp: ? → +
(In reply to Kan-Ru Chen [:kanru] from comment #12)
> Maybe it will also happen when we apply update? I don't know how to test that.

I've just confirmed this does happen after an update is applied when the screen is off.
Keywords: dogfood
The gralloc HAL is getting EPERM when trying to open /dev/graphics/fb0.  I think I may know how to fix this.
.... aaaand it turns out fabrice already wrote the same fix, but after several rounds of refactoring, his workaround is no longer running in time.  I'm quite confident that just moving it back into the right place will make all these problems go away.
Created attachment 656766 [details] [diff] [review]
Move this workaround back into the right place
Assignee: kchen → jones.chris.g
Attachment #656766 - Flags: review?(fabrice)
Attachment #656766 - Flags: review?(fabrice) → review+
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18


3 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.