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

RESOLVED FIXED in Firefox 55

Status

()

RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: garbas, Assigned: jld)

Tracking

({crash})

unspecified
mozilla55
Unspecified
Linux
crash
Points:
---

Firefox Tracking Flags

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

Details

(Whiteboard: sb+, crash signature)

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-49304330-ed12-47f4-9444-027cd2161210.
=============================================================
(Assignee)

Comment 1

2 years ago
$ 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
(Assignee)

Updated

2 years ago
Summary: Crash in libc-2.24.so@0xda657 → Crash in libc-2.24.so@0xda657 (utime)

Updated

2 years ago
Whiteboard: sb+
(Assignee)

Comment 2

2 years ago
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
(Assignee)

Updated

2 years ago
See Also: → bug 1294528
(Assignee)

Updated

2 years ago
Depends on: 1325242
(Assignee)

Comment 3

2 years ago
(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.
(Assignee)

Updated

a year ago
Crash Signature: [@ libc-2.24.so@0xda657] → [@ libc-2.24.so@0xda657 ] [@ libc-2.25.so@0xda8a7 ]
(Assignee)

Updated

a year ago
No longer depends on: 1325242
See Also: → bug 1325242
Comment hidden (mozreview-request)

Comment 6

a year 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+
(Assignee)

Comment 7

a year ago
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)

Updated

a year ago
Assignee: nobody → jld

Comment 8

a year 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

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/fe87806bd7f4
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Is this something that affects ESR52? I forgot what the status of sandboxing is there.
status-firefox53: --- → wontfix
status-firefox54: --- → wontfix
status-firefox-esr52: --- → ?
Flags: needinfo?(jld)
(Assignee)

Comment 11

a year ago
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.)
status-firefox-esr52: ? → unaffected
Flags: needinfo?(jld)
You need to log in before you can comment on or make changes to this bug.