Bus error in gfxSparseBitSet::Union
Categories
(Core :: Graphics, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox89 | --- | fixed |
People
(Reporter: petr.sumbera, Assigned: jfkthame)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
This is Solaris SPARC (big endian) issue:
Thread 2 received signal SIGBUS, Bus error.
0x00007db8b3c98854 in gfxSparseBitSet::Union (this=0x7ecc29dc95d8, aBitset=...) at /builds/psumbera/FIREFOX/gfx/thebes/gfxFontUtils.h:520
520 dst[j] |= src[j];
Seems that src should be rounded by 8 which isn't!?
(gdb) frame
#0 0x00007db8b3c98854 in gfxSparseBitSet::Union (this=0x7ecc29dc95d8, aBitset=...) at /builds/psumbera/FIREFOX/gfx/thebes/gfxFontUtils.h:520
520 dst[j] |= src[j];
(gdb) print j
$1 = 0
(gdb) print dst
$2 = (uint32_t *) 0x7db884db6a08
(gdb) print src
$3 = (const uint32_t *) 0x7db8d6372fe6
Stack is:
#0 0x00007db8b3c98854 in gfxSparseBitSet::Union(SharedBitSet const&) (this=0x7ecc29dc95d8, aBitset=...) at /builds/psumbera/FIREFOX/gfx/thebes/gfxFontUtils.h:520
#1 0x00007db8b3c5b2bc in mozilla::fontlist::Family::SetupFamilyCharMap(mozilla::fontlist::FontList*) (this=0x7db8d70711e0, aList=0x7db894820b70)
at /builds/psumbera/FIREFOX/gfx/thebes/SharedFontList.cpp:513
#2 0x00007db8b3d09d28 in gfxPlatformFontList::InitializeFamily(mozilla::fontlist::Family*, bool) (this=0x7db896eb5000, aFamily=0x7db8d70711e0, aLoadCmaps=true)
at /builds/psumbera/FIREFOX/gfx/thebes/gfxPlatformFontList.cpp:1569
#3 0x00007db8b3d493c0 in LoadCmapsRunnable::Run() (this=0x7db888885b50) at /builds/psumbera/FIREFOX/gfx/thebes/gfxPlatformFontList.cpp:1265
#4 0x00007db8b1350cd8 in mozilla::RunnableTask::Run() (this=0x7db884c06160) at /builds/psumbera/FIREFOX/xpcom/threads/TaskController.cpp:472
#5 0x00007db8b13464e0 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)
(this=0x7db8d6765a00, aProofOfLock=...) at /builds/psumbera/FIREFOX/xpcom/threads/TaskController.cpp:760
#6 0x00007db8b1345c4c in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&)
(this=0x7db8d6765a00, aProofOfLock=...) at /builds/psumbera/FIREFOX/xpcom/threads/TaskController.cpp:634
#7 0x00007db8b1344c44 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7db8d6765a00, aMayWait=false)
at /builds/psumbera/FIREFOX/xpcom/threads/TaskController.cpp:395
#8 0x00007db8b1343588 in mozilla::TaskController::<lambda()>::operator()(void) const (__closure=0x7db8d67fb698)
at /builds/psumbera/FIREFOX/xpcom/threads/TaskController.cpp:133
#9 0x00007db8b13493a8 in mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::<lambda()> >::Run(void) (this=0x7db8d67fb670)
at /builds/psumbera/FIREFOX/xpcom/threads/nsThreadUtils.h:534
#10 0x00007db8b138012c in nsThread::ProcessNextEvent(bool, bool*) (this=0x7db89fc28060, aMayWait=false, aResult=0x7ecc29dca677)
at /builds/psumbera/FIREFOX/xpcom/threads/nsThread.cpp:1158
#11 0x00007db8b1390b34 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7db89fc28060, aMayWait=false) at /builds/psumbera/FIREFOX/xpcom/threads/nsThreadUtils.cpp:548
#12 0x00007db8b24790d0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7db89fc8ff00, aDelegate=0x7db8d67b6b70)
at /builds/psumbera/FIREFOX/ipc/glue/MessagePump.cpp:87
#13 0x00007db8b2392888 in MessageLoop::RunInternal() (this=0x7db8d67b6b70) at /builds/psumbera/FIREFOX/ipc/chromium/src/base/message_loop.cc:335
#14 0x00007db8b23927b0 in MessageLoop::RunHandler() (this=0x7db8d67b6b70) at /builds/psumbera/FIREFOX/ipc/chromium/src/base/message_loop.cc:328
#15 0x00007db8b2392750 in MessageLoop::Run() (this=0x7db8d67b6b70) at /builds/psumbera/FIREFOX/ipc/chromium/src/base/message_loop.cc:310
#16 0x00007db8b87aa638 in nsBaseAppShell::Run() (this=0x7db89fc30160) at /builds/psumbera/FIREFOX/widget/nsBaseAppShell.cpp:137
#17 0x00007db8bb277968 in nsAppStartup::Run() (this=0x7db89fc62250) at /builds/psumbera/FIREFOX/toolkit/components/startup/nsAppStartup.cpp:271
#18 0x00007db8bb4c6c6c in XREMain::XRE_mainRun() (this=0x7ecc29dcb030) at /builds/psumbera/FIREFOX/toolkit/xre/nsAppRunner.cpp:5303
#19 0x00007db8bb4c7e90 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=0x7ecc29dcb030, argc=1, argv=0x7ecc29dcb878, aConfig=...)
at /builds/psumbera/FIREFOX/toolkit/xre/nsAppRunner.cpp:5495
#20 0x00007db8bb4c8198 in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=1, argv=0x7ecc29dcb878, aConfig=...)
at /builds/psumbera/FIREFOX/toolkit/xre/nsAppRunner.cpp:5558
#21 0x00007db8bb4e1aec in mozilla::BootstrapImpl::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=0x7db8d67486e0, argc=1, argv=0x7ecc29dcb878, aConfig=...)
at /builds/psumbera/FIREFOX/toolkit/xre/Bootstrap.cpp:45
#22 0x00007db8d7c75920 in do_main(int, char**, char**) (argc=1, argv=0x7ecc29dcb878, envp=0x7ecc29dcb888) at /builds/psumbera/FIREFOX/browser/app/nsBrowserApp.cpp:220
#23 0x00007db8d7c75e2c in main(int, char**, char**) (argc=1, argv=0x7ecc29dcb878, envp=0x7ecc29dcb888) at /builds/psumbera/FIREFOX/browser/app/nsBrowserApp.cpp:347
| Reporter | ||
Comment 1•4 years ago
|
||
Jonathan, any idea about this code:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxFontUtils.h#306 ?
Can we make it aligned to 8 bytes?
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
| Assignee | ||
Comment 3•4 years ago
|
||
(In reply to Petr Sumbera from comment #1)
Jonathan, any idea about this code:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxFontUtils.h#306 ?
Can we make it aligned to 8 bytes?
The code does not currently ensure anything more than 2-byte alignment for the Block records in a SharedBitSet. We could presumably make that 4-byte alignment, which should be sufficient here, by including padding after the block index array if necessary; but that would also complicate the computation of the actual block offsets.
Instead, I think we should just remove the "optimization" of iterating over the block in 4-byte chunks, and do it byte-by-byte. This will avoid any alignment issues.
| Assignee | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Comment 6•4 years ago
|
||
| bugherder | ||
Description
•