Closed Bug 1405940 Opened 8 years ago Closed 8 years ago

Crash - WebRtc - Null Pointer dereference in sigslot::lock_block

Categories

(Core :: WebRTC: Signaling, defect, P2)

51 Branch
x86
All
defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: loobenyang, Assigned: mjf)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(2 files)

Reproduction test case: NullPtr_sigslot_lock_block_Repro.htm Steps to reproduce: 1. Open PoC NullPtr_sigslot_lock_block_Repro.htm in Firefox browser. 2. Firefox crashes by dereferenceing NULL pointer in sigslot::lock_block<sigslot::single_threaded>::{ctor}. Firefox version: 58.0a1 (2017-10-04) (32-bit) OS: Windows 10 Stack trace: (22e4.1904): Access violation - code c0000005 (!!! second chance !!!) eax=00000014 ebx=00000010 ecx=00000014 edx=05f44618 esi=00000014 edi=221fcc78 eip=10aab053 esp=07ffecd0 ebp=07ffece4 iopl=0 nv up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206 xul!sigslot::lock_block<sigslot::single_threaded>::{ctor}+0x2 [inlined in xul!sigslot::signal2<mozilla::TransportLayer *,enum mozilla::TransportLayer::State,sigslot::single_threaded>::connect<mozilla::PeerConnectionMedia>+0x17]: 10aab053 8b06 mov eax,dword ptr [esi] ds:002b:00000014=???????? 5:216> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* FAULTING_IP: xul!sigslot::signal2<mozilla::TransportLayer *,enum mozilla::TransportLayer::State,sigslot::single_threaded>::connect<mozilla::PeerConnectionMedia>+17 [z:\build\build\src\media\mtransport\sigslot.h @ 2320] 10aab053 8b06 mov eax,dword ptr [esi] EXCEPTION_RECORD: (.exr -1) ExceptionAddress: 10aab053 (xul!sigslot::lock_block<sigslot::single_threaded>::{ctor}+0x00000002) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000014 Attempt to read from address 00000014 FAULTING_THREAD: 00001904 DEFAULT_BUCKET_ID: NULL_CLASS_PTR_READ PROCESS_NAME: firefox.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 00000014 READ_ADDRESS: 00000014 FOLLOWUP_IP: xul!sigslot::signal2<mozilla::TransportLayer *,enum mozilla::TransportLayer::State,sigslot::single_threaded>::connect<mozilla::PeerConnectionMedia>+17 [z:\build\build\src\media\mtransport\sigslot.h @ 2320] 10aab053 8b06 mov eax,dword ptr [esi] BUGCHECK_STR: NULL_CLASS_PTR_READ NTGLOBALFLAG: 400 APPLICATION_VERIFIER_FLAGS: 0 APP: firefox.exe ANALYSIS_VERSION: 10.0.10240.9 x86fre LAST_CONTROL_TRANSFER: from 10ae28aa to 10aab053 STACK_TEXT: 07ffece4 10ae28aa 221fcc00 10ae26db 00000000 xul!sigslot::signal2<mozilla::TransportLayer *,enum mozilla::TransportLayer::State,sigslot::single_threaded>::connect<mozilla::PeerConnectionMedia>+0x17 07ffed00 10ae2f32 221fcc00 22602a70 00000000 xul!mozilla::TransportLayerIce::PostSetup+0x3e 07ffedf4 10a98103 29cc0a60 00000000 00000001 xul!mozilla::TransportLayerIce::SetParameters+0x1a7 07ffee34 10a9bab1 22602a70 23230160 00000000 xul!mozilla::AddNewIceStreamForRestart_s+0x6d 07ffee54 0fe7d307 25ba7160 00000001 00000001 xul!mozilla::runnable_args_func<void (__cdecl*)(RefPtr<mozilla::PeerConnectionMedia>,RefPtr<mozilla::TransportFlow>,unsigned int,bool),mozilla::PeerConnectionMedia *,RefPtr<mozilla::TransportFlow>,unsigned int,bool>::Run+0x2c 07fff3c4 0fd70e15 05f19700 00000001 07fff3df xul!nsThread::ProcessNextEvent+0x298 07fff3e0 0fd704c3 05f44610 05f19700 0646e0bc xul!NS_ProcessNextEvent+0x1a 07fff6ac 0fe7d307 05f44610 05f1a5e0 05f19700 xul!mozilla::net::nsSocketTransportService::Run+0x2a2 07fffc18 0fd70e15 05f19700 05f19700 07fffc33 xul!nsThread::ProcessNextEvent+0x298 07fffc34 0fd70d89 05f1a5e0 05f1a5e0 51ec2610 xul!NS_ProcessNextEvent+0x1a 07fffc58 0ffeea46 05f1a5e0 cefd3247 05f19700 xul!mozilla::ipc::MessagePumpForNonMainThreads::Run+0x95 07fffc90 0ffeea04 05f1a5e0 00000001 51ec2600 xul!MessageLoop::RunHandler+0x20 07fffcb0 0ffedd73 76686870 0114e7d0 0114e880 xul!MessageLoop::Run+0x19 07fffcd4 515fb259 0055dfe0 0690f698 515f0cac xul!nsThread::ThreadFunc+0xb7 07fffcf0 515f0cb9 0114e7d0 07fffd38 757ee87f nss3!_PR_NativeRunThread+0xcc 07fffcfc 757ee87f 0114e7d0 a8b96693 757ee840 nss3!pr_root+0xd 07fffd38 76688744 0690f698 00000000 ab4c1143 ucrtbase!_set_app_type+0x4f 07fffd4c 51ecb856 0690f698 757ee840 76688720 KERNEL32!BaseThreadInitThunk+0x24 07fffd60 7706582d 0690f698 aa2cb4d7 00000000 mozglue!patched_BaseThreadInitThunk+0x27 07fffda8 770657fd ffffffff 77086389 00000000 ntdll!__RtlUserThreadStart+0x2f 07fffdb8 00000000 757ee840 0690f698 00000000 ntdll!_RtlUserThreadStart+0x1b FAULTING_SOURCE_LINE: z:\build\build\src\media\mtransport\sigslot.h FAULTING_SOURCE_FILE: z:\build\build\src\media\mtransport\sigslot.h FAULTING_SOURCE_LINE_NUMBER: 2320 FAULTING_SOURCE_CODE: No source found for 'z:\build\build\src\media\mtransport\sigslot.h' SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: xul!sigslot::signal2<mozilla::TransportLayer *,enum mozilla::TransportLayer::State,sigslot::single_threaded>::connect<mozilla::PeerConnectionMedia>+17 FOLLOWUP_NAME: MachineOwner MODULE_NAME: xul IMAGE_NAME: xul.dll DEBUG_FLR_IMAGE_TIMESTAMP: 59d57146 STACK_COMMAND: ~216s ; kb BUCKET_ID: NULL_CLASS_PTR_READ_xul!sigslot::signal2_mozilla::TransportLayer_*,enum_mozilla::TransportLayer::State,sigslot::single_threaded_::connect_mozilla::PeerConnectionMedia_+17 PRIMARY_PROBLEM_CLASS: NULL_CLASS_PTR_READ_xul!sigslot::signal2_mozilla::TransportLayer_*,enum_mozilla::TransportLayer::State,sigslot::single_threaded_::connect_mozilla::PeerConnectionMedia_+17 FAILURE_PROBLEM_CLASS: NULL_CLASS_PTR_READ FAILURE_EXCEPTION_CODE: c0000005 FAILURE_IMAGE_NAME: xul.dll FAILURE_FUNCTION_NAME: sigslot::signal2_mozilla::TransportLayer_*,enum_mozilla::TransportLayer::State,sigslot::single_threaded_::connect_mozilla::PeerConnectionMedia_ FAILURE_SYMBOL_NAME: xul.dll!sigslot::signal2_mozilla::TransportLayer_*,enum_mozilla::TransportLayer::State,sigslot::single_threaded_::connect_mozilla::PeerConnectionMedia_ FAILURE_BUCKET_ID: NULL_CLASS_PTR_READ_c0000005_xul.dll!sigslot::signal2_mozilla::TransportLayer_*,enum_mozilla::TransportLayer::State,sigslot::single_threaded_::connect_mozilla::PeerConnectionMedia_ ANALYSIS_SOURCE: UM FAILURE_ID_HASH_STRING: um:null_class_ptr_read_c0000005_xul.dll!sigslot::signal2_mozilla::transportlayer_*,enum_mozilla::transportlayer::state,sigslot::single_threaded_::connect_mozilla::peerconnectionmedia_ FAILURE_ID_HASH: {2f47a0ca-22ea-c1e0-1940-4ec853c0fa14} Followup: MachineOwner ---------
Nils, could you take a look at this?
Flags: needinfo?(drno)
Rank: 15
Component: WebRTC → WebRTC: Signaling
Priority: -- → P2
Michael I think this might be either related to the bugs you are working on, or maybe this is even giving you the root cause for the crashes. Can you take a look a this please?
Flags: needinfo?(drno) → needinfo?(mfroman)
Looking at it.
Flags: needinfo?(mfroman)
Assignee: nobody → mfroman
Comment on attachment 8919910 [details] Bug 1405940 - Fix Null Pointer dereference in sigslot::lock_block https://reviewboard.mozilla.org/r/190844/#review196056
Attachment #8919910 - Flags: review?(docfaraday)
Comment on attachment 8919910 [details] Bug 1405940 - Fix Null Pointer dereference in sigslot::lock_block https://reviewboard.mozilla.org/r/190844/#review196360
Attachment #8919910 - Flags: review+
Pushed by mfroman@nostrum.com: https://hg.mozilla.org/integration/autoland/rev/03bb347a9e4d Fix Null Pointer dereference in sigslot::lock_block r=bwc
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
INFO: Last good revision: 6cf0089510fad8deb866136f5b92bbced9498447 (2016-08-10) INFO: First bad revision: 0502bd9e025edde29777ba1de4280f9b52af4663 (2016-08-11) INFO: Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6cf0089510fad8deb866136f5b92bbced9498447&tochange=0502bd9e025edde29777ba1de4280f9b52af4663 Could we have landed a test for this?
Crash Signature: [@ mozilla::TransportLayerIce::PostSetup ]
Has Regression Range: --- → yes
Flags: needinfo?(mfroman)
Flags: in-testsuite?
Version: 58 Branch → 51 Branch
That sounds like a good idea. Lets at least put a jsep unit test.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > INFO: Last good revision: 6cf0089510fad8deb866136f5b92bbced9498447 > (2016-08-10) > INFO: First bad revision: 0502bd9e025edde29777ba1de4280f9b52af4663 > (2016-08-11) > INFO: Pushlog: > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=6cf0089510fad8deb866136f5b92bbced9498447&tochange=0502 > bd9e025edde29777ba1de4280f9b52af4663 > > Could we have landed a test for this? Given that the crash log graph shows this happening as early as May 2017, I'm not sure that pushlog is a good indicator of what caused this. The test html file attachment that reproduces this needed to run for a non-determinant time to cause the crash. I'm not sure if a one-shot jsep unit test will be a reliable way to detect this issue. I'll take a look, and if so, I'll open another bug for the test addition.
Flags: needinfo?(mfroman)
See Also: → 1413709
Flags: in-testsuite? → in-testsuite+
(In reply to Michael Froman [:mjf] from comment #12) > (In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > > Could we have landed a test for this? > > Given that the crash log graph shows this happening as early as May 2017, > I'm not sure that pushlog is a good indicator of what caused this. > > The test html file attachment that reproduces this needed to run for a > non-determinant time to cause the crash. I'm not sure if a one-shot jsep > unit test will be a reliable way to detect this issue. I'll take a look, > and if so, I'll open another bug for the test addition. I meant at least a test for not allowing rollbacks via SDP answers.
(In reply to Nils Ohlmeier [:drno] from comment #13) > (In reply to Michael Froman [:mjf] from comment #12) > > (In reply to Ryan VanderMeulen [:RyanVM] from comment #10) > > > Could we have landed a test for this? > > > > Given that the crash log graph shows this happening as early as May 2017, > > I'm not sure that pushlog is a good indicator of what caused this. > > > > The test html file attachment that reproduces this needed to run for a > > non-determinant time to cause the crash. I'm not sure if a one-shot jsep > > unit test will be a reliable way to detect this issue. I'll take a look, > > and if so, I'll open another bug for the test addition. > > I meant at least a test for not allowing rollbacks via SDP answers. The problem that I saw in the test file for this bug wasn't rollbacks via SDP answers, it was inappropriate restarts by the answerer (ICE creds changing on the answer when they didn't on the offer). I covered the tests in Bug 1413709 (both jsep session unit tests and mochitests). Let me know if you think I solved the wrong problem, and I'll come back to the tests.
See Also: → 1389793
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: