Closed Bug 740253 Opened 12 years ago Closed 12 years ago

webrtc/signaling code has bad pointer errors in cpr/ipc

Categories

(Core :: WebRTC: Signaling, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 806407

People

(Reporter: ehugg, Unassigned)

Details

(Whiteboard: [WebRTC], [blocking-webrtc+])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:


==18752== Syscall param msgsnd(msgp->mtype) points to uninitialised byte(s)
==18752==    at 0x31516E2873: ??? (syscall-template.S:82)
==18752==    by 0x7F1D298: cprPostMessage (cpr_linux_ipc.c:808)
==18752==    by 0x7F1DAAD: cprSendMessage (cpr_linux_ipc.c:669)
==18752==    by 0x7E84147: ccappTaskSendMsg (ccapp_task.c:162)
==18752==    by 0x7E841DD: ccappTaskPostMsg (ccapp_task.c:129)
==18752==    by 0x7E7DB1A: cc_invokeDeviceFeature (cc_device_feature.c:52)
==18752==    by 0x7E7DB85: CC_DeviceFeature_enableVideo (cc_device_feature.c:84)
==18752==    by 0x7E8022C: CCAPI_Device_enableVideo (ccapi_device.c:161)
==18752==    by 0x7F475B4: CSF::CC_SIPCCDevice::CC_SIPCCDevice(unsigned int) (CC_SIPCCDevice.cpp:114)
==18752==    by 0x7F4822A: CSF::CC_SIPCCDevice::wrap(unsigned int) (Wrapper.h:96)
==18752==    by 0x7F546FC: CSF::CC_SIPCCService::onDeviceEvent(ccapi_device_event_e, unsigned int, cc_device_info_t_*) (CC_SIPCCService.cpp:714)
==18752==    by 0x7E832BE: ccsnap_gen_deviceEvent (ccapi_snapshot.c:449)
==18752==  Address 0x7feffa974 is on thread 1's stack
==18752==
Created socket 2
==18752== Thread 32:
==18752== Syscall param msgsnd(msgp->mtype) points to uninitialised byte(s)
==18752==    at 0x31516E2873: ??? (syscall-template.S:82)
==18752==    by 0x7F1D298: cprPostMessage (cpr_linux_ipc.c:808)
==18752==    by 0x7F1DAAD: cprSendMessage (cpr_linux_ipc.c:669)
==18752==    by 0x7F05A67: SIPTaskSendMsg (ccsip_task.c:371)
==18752==    by 0x7E8A165: send_protocol_config_msg (init.c:467)
==18752==    by 0x7E872A6: ccp_handler (ccprovider.c:1768)
==18752==    by 0x7E842AD: CCApp_task (ccapp_task.c:199)
==18752==    by 0x3151A07B40: start_thread (pthread_create.c:305)
==18752==    by 0x31516E0E6C: clone (clone.S:115)
==18752==  Address 0x167becf4 is on thread 32's stack
=
==18752== Thread 31:
==18752== Syscall param msgsnd(msgp->mtype) points to uninitialised byte(s)
==18752==    at 0x31516E2873: ??? (syscall-template.S:82)
==18752==    by 0x7F1D298: cprPostMessage (cpr_linux_ipc.c:808)
==18752==    by 0x7F1DAAD: cprSendMessage (cpr_linux_ipc.c:669)
==18752==    by 0x7F20ABE: timerThread (cpr_linux_timers_using_select.c:1305)
==18752==    by 0x3151A07B40: start_thread (pthread_create.c:305)
==18752==    by 0x31516E0E6C: clone (clone.S:115)
==18752==  Address 0x37153d74 is on thread 31's stack
==18752==
c
OS: Mac OS X → Linux
Hardware: x86 → x86_64
QA Contact: jsmith
Whiteboard: [WebRTC], [blocking-webrtc+]
have we seen this in the last 8 months?  I haven't seen this in ages.  Suggest we close
I think this is exactly the bug I just fixed in Bug 806407.  The system call thinks it's a long, but we only set the first four bytes so the next four are uninitialized.  I'm going to mark this as a duplicate of 806407.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.