cprGetMessage apparent stack corruption

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
6 years ago
3 years ago

People

(Reporter: dmose, Assigned: dmose)

Tracking

Trunk
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Assignee)

Description

6 years ago
Created attachment 694984 [details] [diff] [review]
fix android IPC apparent stack corruption

The compiler noticed this: the original code passed the address of a pointer on the stack rather than of a structure to gettimeofday().  It's not clear whether this actually was causing problems.  However, the code didn't actually use that info anyway, so this patch simply stops requesting it entirely.
Attachment #694984 - Flags: review?(ekr)
(Assignee)

Comment 1

6 years ago
Patch also fixes a couple of warnings about disallowed interspersing of code and variable declarations.
Whiteboard: [WebRTC], [blocking-webrtc-]

Comment 2

4 years ago
Dan, is this still relevant?
Flags: needinfo?(dmose)
(Assignee)

Comment 3

4 years ago
I don't know.  If the code is still there and in this state, there's may be a super tiny code-size win here.
Flags: needinfo?(dmose)

Comment 4

4 years ago
Comment on attachment 694984 [details] [diff] [review]
fix android IPC apparent stack corruption

Review of attachment 694984 [details] [diff] [review]:
-----------------------------------------------------------------

rerouting to byron
Attachment #694984 - Flags: review?(ekr) → review?(docfaraday)

Comment 5

4 years ago
Comment on attachment 694984 [details] [diff] [review]
fix android IPC apparent stack corruption

Review of attachment 694984 [details] [diff] [review]:
-----------------------------------------------------------------

::: media/webrtc/signaling/src/sipcc/cpr/android/cpr_android_ipc.c
@@ +180,5 @@
>      static const char fname[] = "cprCreateMessageQueue";
>      cpr_msg_queue_t *msgq;
>      static int key_id = 100; /* arbitrary starting number */
> +    pthread_cond_t _cond = PTHREAD_COND_INITIALIZER;
> +    pthread_mutex_t _lock = PTHREAD_MUTEX_INITIALIZER;

We will leak these if cpr_calloc fails below. Why don't we just do something like msgq->cond = PTHREAD_COND_INITIALIZER? What are the temp variables for anyway?
Attachment #694984 - Flags: review?(docfaraday) → review-

Updated

4 years ago
Depends on: 1080765

Comment 6

3 years ago
sdparta removed this function
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.