Closed Bug 740253 Opened 14 years ago Closed 13 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: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.