Skip to content

Assertion `!is_in_untraced_syscall() || 0 == (SYSCALLBUF_LOCKED_TRACEE & read_mem(REMOTE_PTR_FIELD(syscallbuf_child, locked)))' failed to hold.  #2276

Closed

Description

@gabrielesvelto

I've just run into this assertion while debugging a Firefox marionette test in chaos mode:

[FATAL /var/tmp/portage/dev-util/rr-5.2.0/work/rr-5.2.0/src/Task.cc:2017:reset_syscallbuf()]
(task 22180 (rec:22180) at time 2076543)
-> Assertion `!is_in_untraced_syscall() || 0 == (SYSCALLBUF_LOCKED_TRACEE & read_mem(REMOTE_PTR_FIELD(syscallbuf_child, locked)))' failed to hold.
=== Start rr backtrace:
rr(_ZN2rr13dump_rr_stackEv+0x41)[0x564ef24159b1]
rr(_ZN2rr9GdbServer15emergency_debugEPNS_4TaskE+0x5c5)[0x564ef233ff45]
rr(_ZN2rr21EmergencyDebugOstreamD1Ev+0x11e)[0x564ef234df6e]
rr(_ZN2rr4Task16reset_syscallbufEv+0xb3)[0x564ef23fd673]
rr(_ZN2rr10RecordTask22maybe_reset_syscallbufEv+0xb0)[0x564ef23af070]
rr(_ZN2rr10RecordTask12record_eventERKNS_5EventENS0_15FlushSyscallbufEPKNS_9RegistersE+0x164)[0x564ef23ae744]
rr(+0xbaa0b)[0x564ef236da0b]
rr(_ZN2rr13RecordSession11record_stepEv+0x2b9)[0x564ef2371f19]
rr(_ZN2rr13RecordCommand3runERSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE+0x95f)[0x564ef2367cbf]
rr(main+0x1da)[0x564ef22f20fa]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f327500b011]
rr(_start+0x2a)[0x564ef22f22ca]
=== End rr backtrace

I hit this twice while running the tests with the following command:

./mach marionette-test -z testing/marionette/harness/marionette_harness/tests/unit/test_select.py testing/marionette/harness/marionette_harness/tests/unit/test_crash.py

This was on mozilla-central revision 90853a59691e with a local build. I could reproduce the issue twice in four runs so it's not hard to reproduce. I can provide all the build details if needed (mozconfig contents, etc...). BTW this was on Gentoo Linux, kernel 4.14.65 and glibc 2.26.

Activity

  1. khuey commented on Oct 8, 2018

    @khuey
    Collaborator

    Can you get the tracee stack at this moment?

  2. gabrielesvelto commented on Oct 9, 2018

    @gabrielesvelto
    Author

    I'm not sure if I've done it correctly but it seems it's stuck during ELF loading:

    #0  0x0000000070000017 in _start () from /lib64/ld-linux-x86-64.so.2
    #1  0x0000000070005f61 in open_verify (name=0x2000010007 <error: Cannot access memory at address 0x2000010007>, fbp=0x0, loader=<optimized out>, whatcode=<optimized out>, 
        mode=<optimized out>, found_other_class=0x7fa93307423e, free_name=8, fd=0) at dl-load.c:1657
    #2  0x0000002000010007 in ?? ()
    #3  0x0000000100000008 in ?? ()
    #4  0x0001000100000009 in ?? ()
    #5  0x0000000000000000 in ?? ()
    
  3. rocallahan commented on Jan 1, 2024

    @rocallahan
    Collaborator

    Obsolete. Sorry we didn't get to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions