Re: plugin container question

[Benjamin Smedberg]

On 12/23/2011 10:09 AM, William Barnacle wrote:
> I made a debug version of FF 9.0.1 and debugged by attaching to
> plugin-container. It's impossible to get a useful stack trace at the
> point of the error, because the crash is caused by a "stack overflow".
Sure, but you would normally still have a stack... it would be good to
see what the recursive pattern is. In the other message you quoted there
aren't symbols for Mozilla or Microsoft libs, which makes it difficult
to diagnose ;-)

Also, let's move this discussion to mozilla.dev.tech.plugins

--BDS

[William Barnacle]

Ok, well, the following 6 year old message from mozilla.dev.tech.plugins
had the exact clue that I needed. Now the demo works and I can move
on. Thanks one and all for the help!
-- BB


> -------- Original Message --------
> Subject: OpenGL initialization: stack overflow
> Date: Tue, 28 Mar 2006 16:35:11 +0200
> From: Aras Pranckevicius <nea...@gmail.com>
> Reply-To: Aras Pranckevicius <nea...@gmail.com>
> Organization: nesnausk!
> Newsgroups: mozilla.dev.tech.plugins
>
> Hi,
>
> I'm having troubles initializing OpenGL in a Firefox (1.5.0.1) plugin on
> windows. Whenever I'd call SetPixelFormat on window's device context, I'd
> get stack overflow (infinite call chain) when resizing the plugin window.
>
> After lots of debugging, I came to a minimal repro case, that basically does
> this: in HTML file, the <embed> element for the plugin is not in pixels, but
> in percentages - so it changes size when changing browser window size.
>
> Now, if I do this:
> 1) in NPP_SetWindow, get the win32 window handle and store it
> 2) later (on first paint message) initialize OpenGL
> 3) everything goes fine, until you resize the window - then _before_
> NPP_SetWindow is even called, I get stack overflow, stacktrace repeats like:
> user32.dll!77d485da()
> user32.dll!77d4876b()
> user32.dll!77d4c63f()
> user32.dll!77d4c665()
> opengl32.dll!5ed2699b()
> user32.dll!77d48734()
> user32.dll!77d48816()
> user32.dll!77d4c63f()
> user32.dll!77d4e905()
> firefox.exe!00507abd()
> firefox.exe!0050785c()
> user32.dll!77d48734()
> user32.dll!77d48816()
> user32.dll!77d4c63f()
> user32.dll!77d4c665()
> opengl32.dll!5ed2699b()
> <...> repeat lots of times
>
> The calls do not originate from my code; it's something called from Firefox.
>
>
> Now, if instead of the above I do this:
> 1) in NPP_SetWindow, get the win32 window handle, store it and immediately
> initialize OpenGL.
>
> then everything works fine. The documentation says that the window passed to
> NPP_SetWindow is valid for the life of the plugin, or till another
> NPP_SetWindow call.
>
>
> So, how the first scenario is different? The crucial call seems to be
> SetPixelFormat - if I omit that, I don't get the stack overflow (but then I
> don't have OpenGL properly initialized either).
>
>
> --
> Aras 'NeARAZ' Pranckevicius
> work: www.unity3d.com
> home: nesnausk.org/nearaz
_____________________________________________________________

[yooyo]

On Dec 23, 6:10 pm, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> On 12/23/2011 10:09 AM, William Barnacle wrote:> I made a debug version of FF 9.0.1 and debugged by attaching to
> > plugin-container.   It's impossible to get a useful stack trace at the
> > point of the error, because the crash is caused by a "stack overflow".
>
> Sure, but you would normally still have a stack... it would be good to
> see what the recursive pattern is. In the other message you quoted there
> aren't symbols for Mozilla or Microsoft libs, which makes it difficult
> to diagnose ;-)
>
> Also, let's move this discussion to mozilla.dev.tech.plugins
>
> --BDS

I cant belive I hit exactly the same problem. Even more.. when I
change tab plugin crashes.