579127 - Invalid write of size 8 [@ js::ctypes::FunctionType::Call]

Status: RESOLVED DUPLICATE of bug 564739

(Core :: js-ctypes, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: backtraces for all the threads

I'm pretty sure that it's FF Sync causing this hang.  IIRC, I wasn't interacting with the browser when it hung; I switched back to it from the terminal and found it unresponsive.  I've also experienced this hang while interacting with the browser.

The backtrace below is from a trunk build (hg id 717a5256e379), but I've also seen this on today's nightly, Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre

The only other extension I have enabled is Adblock Plus.

I've attached the results of |thread apply all bt| and |thread apply all bt full|.

(gdb) info threads
  17 Thread 0x7f2c6a7fb710 (LWP 14803)  0x00007f2c7461f869 in syscall () from /lib/libc.so.6
  16 Thread 0x7f2c69aff710 (LWP 14804)  0x00007f2c74616f83 in poll () from /lib/libc.so.6
  15 Thread 0x7f2c692fe710 (LWP 14805)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  14 Thread 0x7f2c68afd710 (LWP 14806)  0x00007f2c79948bc9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  13 Thread 0x7f2c66bd2710 (LWP 14807)  0x00007f2c7994b464 in __lll_lock_wait () from /lib/libpthread.so.0
  12 Thread 0x7f2c660ff710 (LWP 14809)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  11 Thread 0x7f2c61ef8710 (LWP 14811)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  10 Thread 0x7f2c616f7710 (LWP 14814)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  9 Thread 0x7f2c5f8ff710 (LWP 14815)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  8 Thread 0x7f2c5ecff710 (LWP 14816)  0x00007f2c79948bc9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  7 Thread 0x7f2c5deff710 (LWP 14817)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  6 Thread 0x7f2c5cefd710 (LWP 14819)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  5 Thread 0x7f2c5d6fe710 (LWP 14820)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  4 Thread 0x7f2c5b2ff710 (LWP 14823)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
  3 Thread 0x7f2c626f9710 (LWP 14826)  0x00007f2c7994b464 in __lll_lock_wait () from /lib/libpthread.so.0
  2 Thread 0x7f2c5bcfe710 (LWP 14829)  0x00007f2c7994885c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
* 1 Thread 0x7f2c79bea820 (LWP 14794)  0x00007f2c7994b464 in __lll_lock_wait () from /lib/libpthread.so.0

Comment 1

[Justin Lebar (not reading bugmail)]

Oh, and I'm running Weave 1.4.1b3

Comment 2

[Justin Lebar (not reading bugmail)]

Looks like maybe this is deadlocking because of a signal?

Thread 1 (Thread 0x7f2c79bea820 (LWP 14794)):
#0  0x00007f2c7994b464 in __lll_lock_wait () from /lib/libpthread.so.0
...
#5  free (ptr=0x7f2c6aa16c00) at ../../../src/memory/jemalloc/jemalloc.c:6064
#6  0x00007f2c78594190 in nsProfileLock::Unlock (this=0x7f2c700c2a88) at nsProfileLock.cpp:678
#7  0x00007f2c785941c5 in nsProfileLock::RemovePidLockFiles () at nsProfileLock.cpp:150
#8  0x00007f2c7859436f in nsProfileLock::FatalSignalHandler (signo=1880211520, info=<value optimized out>, context=<value optimized out>)
    at nsProfileLock.cpp:166
#9  <signal handler called>

And two other threads are waiting on locks after a call to malloc().

Comment 3

[Mike Connor [:mconnor]]

What makes you think this is Sync?  Not connecting the dots here.

Comment 4

[Justin Lebar (not reading bugmail)]

(In reply to comment #3)
> What makes you think this is Sync?  Not connecting the dots here.

It started happening almost immediately after I installed Sync, and it hasn't happened since I've disabled it.  I'll of course post back here if I see the hang now that I've disabled the extension.

Comment 5

[Mike Connor [:mconnor]]

Okay, so next step is "what is Sync doing that causes the app to hang?"  We haven't changed much with our core, so this could be jemalloc sucking on x86-64, and we just push it harder (we find obscure JS engine regressions too).

Comment 6

[Justin Lebar (not reading bugmail)]

cjones pointed me to bug 522332, which looks like it's the source of the hang.

Of course, that still means that Weave is misbehaving...

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

My money is on nsExpirationTracker<gfxTextRun, 3u>::AgeOneGeneration triggering a free() of a bad pointer.  valgrind should be able to discern the underlying problem.

Comment 8

[Justin Lebar (not reading bugmail)]

I'll see if I can trigger the issue from FF within Valgrind.

Comment 9

[Justin Lebar (not reading bugmail)]

I immediately get an invalid write upon starting FF under Memcheck with Sync enabled.  I don't get the warning when I disable Sync.

(I asked biesi to make this a security bug before I posted this backtrace, in case it might be harmful.  Looks like maybe a 64-bit bug [writing 8 bytes into something alloc'ed as 4 bytes]?)

==24657== Invalid write of size 8
==24657==    at 0x418A568: ffi_call_unix64 (unix64.S:139)
==24657==    by 0x418A263: ffi_call (ffi64.c:484)
==24657==    by 0x418250E: js::ctypes::FunctionType::Call(JSContext*, JSObject*, unsigned int, long*, long*) (CTypes.cpp:4916)
==24657==    by 0x40B917B: js_Call (jsobj.cpp:5651)
==24657==    by 0x40AE87F: js_Invoke (jscntxtinlines.h:349)
==24657==    by 0x409E5C5: js_Interpret (jsops.cpp:2155)
==24657==    by 0x40AE607: bool Invoke<int (*)(JSContext*, JSObject*, unsigned int, long*, long*)>(JSContext*, JSFunction*, JSScript*, int (*)(JSContext*, JSObject*, unsigned int, long*, long*), js::InvokeArgsGuard const&, unsigned int) (jsinterp.cpp:602)
==24657==    by 0x40AEA1A: js_Invoke (jsinterp.cpp:693)
==24657==    by 0x5D307A1: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (xpcwrappedjsclass.cpp:1689)
==24657==    by 0x5D2B03A: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (xpcwrappedjs.cpp:570)
==24657==    by 0x61957E2: PrepareAndDispatch (xptcstubs_x86_64_linux.cpp:153)
==24657==    by 0x6194CDA: SharedStub (in /home/jlebar/code/moz/ff-clean/valgrind/toolkit/library/libxul.so)
==24657==  Address 0x1a22d000 is 0 bytes inside a block of size 4 alloc'd
==24657==    at 0x4C28939: operator new[](unsigned long) (vg_replace_malloc.c:305)
==24657==    by 0x418267E: js::ctypes::FunctionType::Call(JSContext*, JSObject*, unsigned int, long*, long*) (CTypes.cpp:4430)
==24657==    by 0x40B917B: js_Call (jsobj.cpp:5651)
==24657==    by 0x40AE87F: js_Invoke (jscntxtinlines.h:349)
==24657==    by 0x409E5C5: js_Interpret (jsops.cpp:2155)
==24657==    by 0x40AE607: bool Invoke<int (*)(JSContext*, JSObject*, unsigned int, long*, long*)>(JSContext*, JSFunction*, JSScript*, int (*)(JSContext*, JSObject*, unsigned int, long*, long*), js::InvokeArgsGuard const&, unsigned int) (jsinterp.cpp:602)
==24657==    by 0x40AEA1A: js_Invoke (jsinterp.cpp:693)
==24657==    by 0x5D307A1: nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (xpcwrappedjsclass.cpp:1689)
==24657==    by 0x5D2B03A: nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) (xpcwrappedjs.cpp:570)
==24657==    by 0x61957E2: PrepareAndDispatch (xptcstubs_x86_64_linux.cpp:153)
==24657==    by 0x6194CDA: SharedStub (in /home/jlebar/code/moz/ff-clean/valgrind/toolkit/library/libxul.so)
==24657==    by 0x6194B7A: NS_InvokeByIndex_P (xptcinvoke_x86_64_unix.cpp:208)

Comment 10

[Benjamin Smedberg]

Or sync is misdeclaring some structure/size type on x86-64...

Comment 11

[Mike Connor [:mconnor]]

That'd be in the ctypes impl... cc-ing dolske.

Comment 12

[[e-mail]]

This is the same as bug 564739 -- the underlying problem is that libffi assumes that (for integral types) the return value address is word-sized, rather than the actual size of the type. Which is most visible on 64-bit plats, where it writes 64 bits to a 32 bit space.

The fix is simple, we just need to marshal through a word-sized intermediate. Need to check closure code too.