Closed
Bug 1033627
Opened 10 years ago
Closed 6 years ago
nsNativeCharsetConverter::UnicodeToNative uses iconv() from worker threads in non-thread-safe manner
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla59
People
(Reporter: johns, Unassigned)
References
Details
In bug 1019868 iconv() is randomly failing and asserting. Looking at the logs, this is occasionally occurring from a worker thread. Per |man iconv_open|: > A conversion descriptor contains a conversion state. After creation using iconv_open(), the state is in the initial state. Using iconv(3) modifies the descriptor's conversion state. (This implies that a conversion descriptor can not be used in multiple threads simultaneously.) While this code[1] re-uses the result of iconv_open without thread locks [1] http://dxr.mozilla.org/mozilla-central/source/xpcom/io/nsNativeCharsetUtils.cpp#338
Comment 1•10 years ago
|
||
Why are we using iconv at all here? This is all UTF8 conversions nowadays, right? I thought we had or were going to rip out the non-UTF8 codepaths.
Comment 2•10 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > Why are we using iconv at all here? This is all UTF8 conversions nowadays, > right? > > I thought we had or were going to rip out the non-UTF8 codepaths. Chrome 35 moves to UTF8 only by Aura support, but a few users still use non-UTF8, then they supports non-UTF8 again by the following. https://codereview.chromium.org/323023002
Comment 3•10 years ago
|
||
What can we do to move this forward? Bug 1019868 continues to bite us on an extremely frequent basis.
Comment 4•6 years ago
|
||
Fixed by bug 960957.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in
before you can comment on or make changes to this bug.
Description
•