Closed Bug 560185 Opened 14 years ago Closed 7 years ago

non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**)

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: surkov, Unassigned)

References

Details

(Keywords: access)

Attachments

(1 obsolete file) 

The trunk Firefox build crash when I turn on accessibility what means Firefox is totally unaccessible. Unfortunately I don't have any idea what can be wrong. Any help is appreciated.

Stack:

#0	0x01232aa8 in non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**) at nsObjCExceptions.h:159
#1	0x0116fa1a in -[ChildView accessible] at nsChildView.mm:5955
#2	0x0116b69f in -[ChildView accessibilityIsIgnored] at nsChildView.mm:5995

mozconfig:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff-dbg
mk_add_options MOZ_MAKE_FLAGS="-s -j4"
ac_add_options --enable-accessibility
ac_add_options --enable-debug
ac_add_options --disable-optimize
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.5.sdk
ac_add_options --enable-extensions=default,inspector

OS X snow leopard
Severity: normal → critical
Steven, any ideas?
> Steven, any ideas?

Not really.

> The trunk Firefox build crash when I turn on accessibility

I'm not entirely sure what this means.  Do you crash on startup after
having built with accessibility support?

Does this appear to be a recent problem?  Does it also happen on the
1.9.2 branch?

Last I knew (about a year ago) Mac accessibility support was in pretty
sad shape ... but it didn't crash when I was playing with it.

Once I get more information, I'll try to reproduce these crashes
myself, and see if I can find a solution.
This was definitely something introduced rather recently, within the last three months or so. Last time I built Firefox myself was before Mac builds supported 64 bit and still had that long mozconfig on Snow Leopard. I re-did my tree today and also re-did the MOZCONFIG to the current one as suggested on MDC, WITHOUT the force to 32 bit lines. Last time I built, the shape was bad, but it wasn't completely dead, which it is now.
(In reply to comment #2)

> I'm not entirely sure what this means.

I used to run Accessibility Inspector (Mac util)

>  Do you crash on startup after
> having built with accessibility support?

No. Actually firefox isn't closed since crash is handled internally I think. I run firefox, run accessibiltiy inspector, set breakpoint to [ChildView accessible] and go to accessible->GetNativeInterface() call and get into nsObjCExceptions.h:159 which means a crash if I get right.

> 
> Does this appear to be a recent problem?  Does it also happen on the
> 1.9.2 branch?

Unfortunately I can't check it on 1.9.2 since when I build Firefox on my mac then it's not loaded. That's was a bug which was fixed on trunk only (I don't remember bug number, I could find it if you need).

> Last I knew (about a year ago) Mac accessibility support was in pretty
> sad shape ... but it didn't crash when I was playing with it.

right

> Once I get more information, I'll try to reproduce these crashes
> myself, and see if I can find a solution.

Thank you. Please let me know if you need any additional details.
Please try to find a way to crash without using the Accessibility
Inspector.  Or at least to generate errors in the console.

What do I need to do to trigger a call to [ChildView accessible]?
(In reply to comment #5)

> What do I need to do to trigger a call to [ChildView accessible]?

run accessibility inspector and move mouse over the firefox
>> What do I need to do to trigger a call to [ChildView accessible]?
>
> run accessibility inspector and move mouse over the firefox

Thanks.  But I also need to know how to do this without using the
Accessibility Inspector.
(In reply to comment #7)
> >> What do I need to do to trigger a call to [ChildView accessible]?
> >
> > run accessibility inspector and move mouse over the firefox
> 
> Thanks.  But I also need to know how to do this without using the
> Accessibility Inspector.

I thought accessibility inspector tool should be available on any mac. I tried to debug with a11y inspector and therefore I suggested to use it as easiest way to reproduce. Any way I think you need to run any AT application to start accessibility. It could be voice over (CMD+F5) or accessibility inspector or accessibility verifier tools.
(In reply to comment #5)
> Please try to find a way to crash without using the Accessibility
> Inspector.

I didn't catch you why a11y inspector is not good here.

>  Or at least to generate errors in the console.

Unfortunately I don't see anything related in console, I can see a11y related warnings but they comes from a11y crossplatform part and don't look related with this problem.
> Any way I think you need to run any AT application to start
> accessibility. It could be voice over (CMD+F5) or accessibility
> inspector or accessibility verifier tools.

Thanks.  It's just that debugging two programs' interaction is more
difficult than debugging the operation of one program.  But it may be
that accessibility usually (always?) involves one program querying
another ... in which case I have no choice.  (As you can see, I don't
(yet) know much about accessibility.)

I'll try all these tools, and see if I find any differences in how
they behave.
I think UIElementInspector is the name of the program.
(In reply to comment #10)

> Thanks.  It's just that debugging two programs' interaction is more
> difficult than debugging the operation of one program.  But it may be
> that accessibility usually (always?) involves one program querying
> another ... in which case I have no choice.  (As you can see, I don't
> (yet) know much about accessibility.)

Yes, there are always two programs (server - Firefox and client - AT tool or software).

> I'll try all these tools, and see if I find any differences in how
> they behave.

thank you.

(In reply to comment #11)
> I think UIElementInspector is the name of the program.

I look for "accessibility inspector" in spotlight (at least it works on snow leopard).
I just tried a 32-bit build, and it is only slightly better: In the 64-bit, I didn't see anything. I was told by VoiceOver I was in a dialog but that dialog had no content. The dialog only had the current page's title. In the menus, I only had the Apple and "Minefield" menus available.

In the 32-bit version, I now see the window title, minimize, zoom and close buttons, and I have access to the full menu. However, I still don't have access to the page content, which is a definite change. I also don't see the awesome bar or any other controls any more.

So I suspect that some things are a bit less crashy than in 64-bit, but not particularly good, either.
So Alexander, were your crashes in a 64-bit build?

Have you tried a 32-bit build?

Marco, are you able to reproduce Alexander's crashes?
(In reply to comment #14)
> So Alexander, were your crashes in a 64-bit build?

I'm not sure I got a question, sorry if so. My steps are:

1) Run firefox
2) set breakpoint at http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsChildView.mm#5955
3) run accessibility inspector and mouse move over the firefox
4) breakpoint triggers, try to go into accessible->GetNativeInterface
5) debugger puts me at http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsObjCExceptions.h#159

> Have you tried a 32-bit build?

no, I will
(In reply to comment #15)

So it was in gdb that you set a breakpoint on '-[ChildView
accessible]'?  If so, thanks for the clarification.

You appear to be saying that all your crashes (up to this point)
*have* been in 64-bit builds.

I'm looking forward to your results with 32-bit builds.

(I'm still building, and don't yet have any results of my own.)
(In reply to comment #16)
> (In reply to comment #15)
> 
> So it was in gdb that you set a breakpoint on '-[ChildView
> accessible]'?  If so, thanks for the clarification.

I used xcode to debug. I'm not sure how it works.

> You appear to be saying that all your crashes (up to this point)
> *have* been in 64-bit builds.

right.

> I'm looking forward to your results with 32-bit builds.

I'm building.
(In reply to comment #14)
> Marco, are you able to reproduce Alexander's crashes?

If these are crashes like Alex says that are caught internally, then yes, I definitely see that something is terribly wrong in both 32 and 64 bit, but it's even more wrong in 64 bit than 32 bit as I described in my comment above. I don't get an Apple-typical dialog that offers me to restart the app. I wasn't building for debug, and I wasn't running it in XCode. I purposely built a release build to have the closest to an end-user experience as possible.
Working with opt trunk builds with accessibility enabled (32-bit and
64-bit), I'm not able to reproduce any crashes -- using either
Accessibility Inspector or Accessibility Verifier.  I tested on OS X
10.6.3, running with and without a debugger (gdb).

I don't think there's any way crashes could have been "caught
internally" -- either in the clients (AI and AV) or the server
(Minefield).  So it looks like Marco hasn't been able to reproduce
Alex's crashes, either.

Furthermore, I haven't (using Accessibility Inspector and
Accessibility Verifier) been able to detect any difference in
accessibility behavior of 32-bit and 64-bit builds.  Both expose far
fewer accessible objects than they should -- basically just
OS-provided window "chrome" (e.g. the close, minimize and zoom
buttons) and the contents of the browser's menus.  But the information
available about these objects seems to be identical in 32-bit and
64-bit builds.

I'll do some debug builds, and see if that makes any difference.  But
I suspect Alex's problems have to do with his debugging setup.

Alex, could you try debugging with gdb instead of XCode, and see if
that makes any difference?
> I'll do some debug builds, and see if that makes any difference.

It doesn't.
(In reply to comment #19)

> Alex, could you try debugging with gdb instead of XCode, and see if
> that makes any difference?

No, it don't. I see the same result.

(gdb) break [ChildView accessible]
Breakpoint 1 at 0x4189374ae69916: file /Users/macintosh/mozilla/fx/widget/src/cocoa/nsChildView.mm, line 5942.
(gdb) run
... console output 
... mouse over with a11y inspector runned


Breakpoint 1, -[ChildView accessible] (self=0x11542a090, _cmd=0x1018cdc5f) at /Users/macintosh/mozilla/fx/widget/src/cocoa/nsChildView.mm:5942
5942	  if (!mGeckoChild)
(gdb) next
Current language:  auto; currently objective-c++
5945	  id<mozAccessible> nativeAccessible = nil;
(gdb) next
5947	  nsAutoRetainCocoaObject kungFuDeathGrip(self);
(gdb) next
5948	  nsCOMPtr<nsIWidget> kungFuDeathGrip2(mGeckoChild);
(gdb) next
5949	  nsCOMPtr<nsIAccessible> accessible;
(gdb) next
5950	  mGeckoChild->GetDocumentAccessible(getter_AddRefs(accessible));
(gdb) next
... console output
5951	  if (!mGeckoChild)
(gdb) next
5954	  if (accessible)
(gdb) next
5955	    accessible->GetNativeInterface((void**)&nativeAccessible);
(gdb) step
nsCOMPtr<nsIAccessible>::operator-> (this=0x7fff5fbfd650) at nsCOMPtr.h:796
796	          NS_PRECONDITION(mRawPtr != 0, "You can't dereference a NULL nsCOMPtr with operator->().");
(gdb) step
Warning: the current language does not match this frame.
797	          return get();
(gdb) step
nsCOMPtr<nsIAccessible>::get (this=0x7fff5fbfd650) at nsCOMPtr.h:777
777	          return reinterpret_cast<T*>(mRawPtr);
(gdb) step
Current language:  auto; currently c++
0x0000000101181748 in nsCOMPtr<nsIAccessible>::operator-> (this=0x7fff5fbfd650) at nsCOMPtr.h:797
797	          return get();
(gdb) step
Current language:  auto; currently objective-c++
Warning: the current language does not match this frame.
0x0000000101232aa8 in non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**) () at nsObjCExceptions.h:159
159	}
(gdb) step
-[ChildView accessible] (self=0x11542a090, _cmd=0x1018cdc5f) at /Users/macintosh/mozilla/fx/widget/src/cocoa/nsChildView.mm:5961
5961	  return nativeAccessible;
(gdb)
Could the problem be the returned document accessible pointer is dead? Then it explains why I can't traverse into GetNativeInterface.
(In reply to comment #22)
> Could the problem be the returned document accessible pointer is dead? Then it
> explains why I can't traverse into GetNativeInterface.

It sounds the object is valid, at least the first time. But nsIAccessible::GetNativeInterface can't be called. It sounds like build issue.

Steven, you can traverse into GetNativeInterface, right?
Attached file davidb's mozconfig (obsolete) — 
Here's my mozconfig... I can't recreate this yet.
(In reply to comment #24)
> Created an attachment (id=440210) [details]
> davidb's mozconfig (can't confirm crash)
> 
> Here's my mozconfig... I can't recreate this yet.

crash might be not right word, probably exception is better, the problem is GetNativeInterface() isn't called, that's a reason Firefox content is not accessible at all I think.
I get:
(gdb) step
Current language:  auto; currently objective-c++
Warning: the current language does not match this frame.
0x049a6874 in non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**) () at nsObjCExceptions.h:159
159	}
(gdb) 

I'm not sure the (non-virtual thunk) is anything to worry about. I've never seend the warning about the current language not matching the frame before.
I bet the Valgrind guy can tell teach me.
Attachment #440210 - Attachment description: davidb's mozconfig (can't confirm crash) → davidb's mozconfig
Attachment #440210 - Attachment is obsolete: true
Comment on attachment 440210 [details]
davidb's mozconfig

Obsoleting my mozconfig as I can recreate the warning/exception.
(In reply to comment #26)
> I'm not sure the (non-virtual thunk) is anything to worry about.

OK Google hits tell me I'm wrong.
(In reply to comment #22)

> why I can't traverse into GetNativeInterface

Aha!!  Now I finally understand the problem.  There is no crash here.

I wish you'd told me at first -- it would have saved me a lot of time.

(In reply to comment #25)

> the problem is GetNativeInterface() isn't called

I suspect this isn't true.

But it's easy enough to check -- I'll do that and comment later.

(In reply to comment #26)

> I'm not sure the (non-virtual thunk) is anything to worry about.

As best I can tell you're right -- it *isn't* anything to worry about.
Though it may interfere with the operation of debuggers (as per
comment #22).

Here's the best link I could find on this subject (in a quick Google
search).  Lots of others also refer to it:

http://lists.apple.com/archives/unix-porting/2003/Dec/msg00107.html
(In reply to comment #30)
> (In reply to comment #22)
> 
> > why I can't traverse into GetNativeInterface
> 
> Aha!!  Now I finally understand the problem.  There is no crash here.
> 
> I wish you'd told me at first -- it would have saved me a lot of time.

Sorry for confusion. I used crash word in wrong meaning. I just was confused by that exception code I get into, I thought it should means the crash. 

removing 'crash' word from bug summary.
Summary: non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**) crash → non-virtual thunk to nsAccessibleWrap::GetNativeInterface(void**)
(Following up comment #30)

> (In reply to comment #25)
>
>> the problem is GetNativeInterface() isn't called
>
> I suspect this isn't true.
>
> But it's easy enough to check -- I'll do that and comment later.

I was right.  nsAccessibleWrap::GetNativeInterface() *is* always
called (from [ChildView accessible]).

But nsAccessibleWrap::mNativeWrapper is always NULL, so
nsAccessibleWrap::GetNativeInterface() always returns NULL.  *That's*
the real problem.  I'll eat lunch and try to figure out why it
happens.

By the way, I found this out by adding NSLog() and printf() calls to
the appropriate code.  Sometimes that's really the best way to debug
:-)
> But nsAccessibleWrap::mNativeWrapper is always NULL, so
> nsAccessibleWrap::GetNativeInterface() always returns NULL.
> *That's* the real problem.  I'll eat lunch and try to figure out why
> it happens.

I've figured it out, and will post a patch tomorrow, probably in a
different bug.

This will be major step forward -- it will open up access to all those
accessible objects inside a window, which accessibility clients (like
Accessibility Inspector and Accessibility Verifier) currently miss.
(In reply to comment #33)
> > But nsAccessibleWrap::mNativeWrapper is always NULL, so
> > nsAccessibleWrap::GetNativeInterface() always returns NULL.
> > *That's* the real problem.  I'll eat lunch and try to figure out why
> > it happens.
> 
> I've figured it out, and will post a patch tomorrow, probably in a
> different bug.

Different bug looks like right approach. Thank you for doing this.

This bug should be fixed or if it's gdb bug then we should file bug to it. But this is something that should be figured out, otherwise it's pain to debug the code.
(In reply to comment #33)
> > But nsAccessibleWrap::mNativeWrapper is always NULL, so
> > nsAccessibleWrap::GetNativeInterface() always returns NULL.
> > *That's* the real problem.  I'll eat lunch and try to figure out why
> > it happens.
> 
> I've figured it out, and will post a patch tomorrow, probably in a
> different bug.

Steven, awesome, please cc me on the bug; can review the patch as well.
I can't step into the call to AccessibleWrapper::getNativeObject()
inside nsAccessibleWrap::GetNativeInterface() (which is in turn called
from [ChildView accessible]).  I can't even set a breakpoint on it.

I tested with a 64-bit build (in 64-bit mode gdb) on OS X 10.6.3, and
a 32-bit build on OS X 10.5.8 (also in gdb).

I don't know why this happens, but as best I can tell this it's a bug
in gdb (or in its derivatives -- i.e. whatever XCode uses for
debugging).  So this bug is close to being INVALID.

The string "non-virtual thunk" exists in gdb on multiple platforms (I
looked on Linux and OS X).  If you grep for it in gdb code, you find
that it's used by a "demangler" -- presumably a program that (like
c++filt) deciphers symbols that have gone through C++ name mangling.
The link I cited in comment #30
(http://lists.apple.com/archives/unix-porting/2003/Dec/msg00107.html)
implies that Apple has been working on it (or related problems).  But
the bug doesn't appear to be Apple-specific.

I'm afraid I don't have any more time to spend on this bug.  So if it
bothers you, feel free to open a bug on gdb.  And feel free to look
for ways to work around it.
(Following up comment #37)

I should add that I was testing with builds made with my patch for bug
560939 -- otherwise the code path would never have reached
AccessibleWrapper::getNativeObject().
I agree with comment #37, closing invalid since the fix belongs in compiler/debugger world. Turned out to be a fortunate bug report though!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
(In reply to comment #39)
> I agree with comment #37, closing invalid since the fix belongs in
> compiler/debugger world. Turned out to be a fortunate bug report though!

I'd like to get it fixed on our side even if it's not our bug, otherwise ally debugging on mac is useless.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
I don't know how to classify this ... but it's definitely not a Cocoa Widgets bug.
Component: Widget: Cocoa → General
QA Contact: cocoa → general
I haven't hit that with my a11y work. I am tempted to close this as WFM.
(In reply to Hub Figuiere [:hub] from comment #42)
> I haven't hit that with my a11y work. I am tempted to close this as WFM.

ok, did you tried it under similar conditions?
Is this bug still relevant?
Flags: needinfo?(surkov.alexander)
I used to debug Firefox a11y on OS X lately with no problems. I think the bug can be marked wfm.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 7 years ago
Flags: needinfo?(surkov.alexander)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: