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)

x86_64
Linux
defect
Not set
normal

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
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.
(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
What can we do to move this forward? Bug 1019868 continues to bite us on an extremely frequent basis.
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.