Plugin Loader.exe page fault on read access to (0x7d154a01)

[Sin]

Plugin Loader crashes sometimes, when I'm trying to start video that are using silverlight. It's totally random. It fixes if I restart firefox or refresh page couple of times. Using Xubuntu 12.04 on HP Chromebook 14. I've tried to disable and enable hw acceleration, but it doesn't matter which it is.

[Jeff Goldschrafe (jgoldschrafe)]

I'm hitting the same issue in Pipelight using both 32-bit (Silverlight) and 64-bit (Flash) plugins on a whole pile of different systems. The address and stack trace are not consistent, but the one consistent feature is that the instruction pointer field (EIP on 32-bit Wine, rip on 64-bit Wine) is set to the same address as the reported address of the page fault. I rebuilt wine-staging from the provided Debian source packages using "-O0 -fno-stack-protector" and execstack, but this doesn't appear to have made any significant difference in the incidence of this issue. It occurs frequently at plugin initialization (i.e. page load) and behaves normally during playback.

[Michael Müller (mqchael)]

Your backtrace also contains pa_mainloop_poll function call? This sounds like the problem is related to pulseaudio.

You can try switching to the ALSA backend and check if the problem is gone. The necessary steps are described at http://pipelight.net/cms/faqs/faq-videos-play-very-fast-lag-or-dont-have-sound.html#section_3

[Jeff Goldschrafe (jgoldschrafe)]

Actually, by my testing here (a few hundred crashes), the pa_mainloop_poll appears to be completely incidental. The active module when the crash occurs seems to be effectively random -- it can be the PulseAudio subsystem, winealsa, ntdll, or any number of other things. The only striking commonalities seem to be that the call isn't far from call_thread_func_wrapper (I'm not familiar with the Pipelight code -- is this an entry point?) and that the address on the read fault is always equal to the address of the instruction pointer.

We've also noticed that sel=0067 the base and limit values are always both set to 00000000 at time of crash, but I'm not familiar enough with Wine debugging (what does sel represent?) to know if these are relevant details or not.

[Michael Müller (mqchael)]

In this case I need some more information:

* The distribution you are using
* The output of (as file attachment): pipelight-plugin --system-check
* The console output when using the plugin (see http://pipelight.net/cms/faqs/faq-how-to-capture-debug-output.html)

A new backtrace might also reveal some more information, though I fear that the backtrace is not complete. The one which was attached in the original report

  4 0x7d15497a in libsbc.so.1 (+0x11979) (0x0ae7ea08)
  5 0x7bc83a90 call_thread_func_wrapper+0xb() in ntdll (0x0ae7ea28)

shows that wine creates a new thread and directly calls libsbc.so.1. This doesn't make sense though, as the calling convention for a ThreadProc function is supposed to be stdcall and not cdecl. It is not the first time that winedbg skips some functions and it will most probably need some manual stack unwinding (and a wine version with debug symbols).

If there is anything special about the affected systems (special browser or browser extensions, patched debian packages, ...) then I might needs this information in order to reproduce the bug.