Crash in libc-2.24.so@0xda657 (utime)

RESOLVED FIXED in Firefox 55

Status

()

defect
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: garbas, Assigned: jld)

Tracking

({crash})

unspecified
mozilla55
Unspecified
Linux
Points:
---

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox53 wontfix, firefox54 wontfix, firefox55 fixed)

Details

(Whiteboard: sb+, crash signature)

Attachments

(1 attachment)

Reporter

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-49304330-ed12-47f4-9444-027cd2161210.
=============================================================
$ grep -w $[0x84] /usr/include/asm/unistd_64.h
#define __NR_utime 132

I don't understand why GConf/ORBit would need to modify the filesystem to query the value of a configuration directive.

But, if the “stack” (really just the list of things found in stack memory that look like return addresses, because the crash dump processor doesn't have unwind info for the system libraries) is reasonably close to the truth, the underlying cause is something in content trying to use the nsProtocolProxyService.

And if I had to guess what in a content process would be trying to do that, it'd be WebRTC[1], because I've run into that before, but that doesn't actually show up in the crash so I could be wrong about that.

[1] http://searchfox.org/mozilla-central/rev/3e157ac240611f80df409ae76221d46a31c20dfc/media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp#295
Summary: Crash in libc-2.24.so@0xda657 → Crash in libc-2.24.so@0xda657 (utime)

Updated

3 years ago
Whiteboard: sb+
On further inspection of the call stack, the thing using the proxy service looks like the NPAPI plugin host: http://searchfox.org/mozilla-central/source/dom/plugins/base/nsPluginHost.cpp#281
See Also: → 1294528
(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #2)
> On further inspection of the call stack, the thing using the proxy service
> looks like the NPAPI plugin host:

This was fixed in bug 778201, but we're still seeing occasional crashes in utime via GConf/ORBit from WebRTC (bug 1325242).
Reporter

Comment 4

2 years ago
I can confirm that this is not an issue for packaging Firefox nightly for NixOS anymore.
I can check (in next week) if this are any problem with WebRTC, since I'm using appear.in service quite a lot.
Crash Signature: [@ libc-2.24.so@0xda657] → [@ libc-2.24.so@0xda657 ] [@ libc-2.25.so@0xda8a7 ]
No longer depends on: 1325242
See Also: → 1325242

Comment 6

2 years ago
mozreview-review
Comment on attachment 8872867 [details]
Bug 1322784 - Gently fail utime(), to deal with GConf/ORBit.

https://reviewboard.mozilla.org/r/144372/#review148804

Question still remains why it's doing this. Maybe to avoid re-reading config files for changes or something? I guess we can live with this given that it will end up being remoted.
Attachment #8872867 - Flags: review?(gpascutto) → review+
For reference, this is from a function named giop_tmpdir_init in src/orb/GIOP/giop.c in the orbit2 source:

#if defined (HAVE_UTIME_H) && !defined (G_OS_WIN32)
                /* This seems pretty useless, forget it on Win32 */

                { /* Hide some information ( apparently ) */
                        struct utimbuf utb;
                        memset (&utb, 0, sizeof (utb));
                        utime (newname, &utb);
                }
#endif          

And there's something similar (minus the "pretty useless" comment, which was added several years later) in a function named make_local_tmpdir in linc2/src/linc-protocols.c

The git history goes back to a commit in 2001 that says only “copy from ORBit-stable”.

What it's actually doing (in both cases) is zeroing the mtime and atime on a newly created temporary directory.  I'm not sure what the point is of trying to conceal when the directory was created, but it also doesn't work, because it can't alter the ctime.
Assignee: nobody → jld

Comment 8

2 years ago
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fe87806bd7f4
Gently fail utime(), to deal with GConf/ORBit. r=gcp

Comment 9

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/fe87806bd7f4
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Is this something that affects ESR52? I forgot what the status of sandboxing is there.
Flags: needinfo?(jld)
Thanks for checking.  It's not affected: this is specific to content sandboxing, and ESR52 has only media plugin sandboxing.  (Also, 53 and 54 were affected only as Nightly.)
Flags: needinfo?(jld)
You need to log in before you can comment on or make changes to this bug.