Closed Bug 778261 Opened 9 years ago Closed 9 years ago

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

Categories

(Core Graveyard :: Widget: Gonk, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
mozilla18
blocking-basecamp +

People

(Reporter: kanru, Assigned: cjones)

References

Details

(Keywords: crash, dogfood)

Crash Data

Attachments

(1 file)

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     }
    654
    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
Tested on Otoro, not always reproduce able.

STR:
  adb reboot
  restart b2g a couple of times
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.
Duplicate of this bug: 780709
blocking-basecamp: --- → ?
Kanru, can you check if this is still an issue with the new kernel update?
(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.
Cervantes also reports that new kernel fixed the issue. Close it.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
I saw this again today, perhaps I was just lucky..
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Could this affect gecko updates?
blocking-basecamp: ? → -
This happens quite often. I'm going to investigate into it.
Assignee: nobody → kchen
blocking-basecamp: - → ?
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)
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.
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.
Assignee: kchen → jones.chris.g
Attachment #656766 - Flags: review?(fabrice)
Attachment #656766 - Flags: review?(fabrice) → review+
https://hg.mozilla.org/mozilla-central/rev/5403164748f8
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.