Bug 22143 - Failure to p/invoke in release builds (EntryPointNotFoundException) in certain cases.
Summary: Failure to p/invoke in release builds (EntryPointNotFoundException) in certai...
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 7.9.1.x
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2014-08-16 19:24 UTC by Brian Berry
Modified: 2016-05-25 00:50 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Brian Berry 2014-08-16 19:24:46 UTC
Observed: An iOS app with a native library component fails to
p/invoke in inconsistent/unexplained ways.

(I'm working on a test case I can upload, but so far
simplified cases all work okay---however, the exercise
has resulted in some interesting info.)

  * The same code + native library work without issue in Debug.
  * The invocation that fails is within asynchronous code kicked
    off via an initial Task.Run(async () => {...}); fired from the
    main view's constructor.
  * The exception observed downstream in an async/await chain is
    EntryPointNotFoundException for a valid entry point.
  * I transplanted the native library to a test app that invokes
    the same method within the AppDelegate.FinishedLaunching method.
    P/invokes work fine within that test app.  No repro yet, though
    I will attempt to add some of the async complexity into that app
    to see if I can provoke it.
  * When stumped, I decided to rule out the async bits by, in the
    complex app, calling the same method identically as I did in
    the test app (in AppDelegate.FinishedLaunching).
  * Doing so resulted in p/invoke SUCCESS at this initial call
    within the complex app.
  * Furthermore, doing so also fixed the _original_ async context
    that, without the added test call, was causing trouble before.

So it appears there may be some kind of race or other issue where
an earlier call to a method results in the binding activity required
before other contexts can successfully p/invoke.  Perhaps the early
kick of an async p/invoker results in it getting a chance to try
a call before, say, the main thread has finished bootstrapping
or whatever...and the difference in timing between debug/release
mattered in this case.  Total speculation, of course, without
a better understanding of the underlying implementation, which
you will certainly have.

I'll update as I find more, upload anything that I can.

Comment 1 Brian Berry 2014-08-16 19:26:40 UTC
Forgot to add (since the version isn't available in the drop down):

Version: (Indie Edition)
Hash: 1686c40
Build date: 2014-08-11 15:30:23-0400
Comment 2 Alex Soto [MSFT] 2014-08-27 17:33:11 UTC
Can you try adding -nosymbolstrip to your additional mtouch args found in project settings to the release configuration?

Comment 3 Brian Berry 2014-08-28 13:00:37 UTC
The addition of the argument (after subtracting my original appeasements to get things running) did change the outcome to proper function.

Additional insight discovered while working back to a "broken" state:
   * My original appeasement was to declare [DllImport....] the offending
     method (just chose the first to be called/fail) within the body of
     my UIApplicationDelegate subclass, plus a call to this method
     from the FinishedLaunching(UIApplication, NSDictionary) override.
  * I discovered that the call to the DLL function was *not* necessary.  The
    declaration alone was all that was needed to mutate failure -> success.

I am curious about what your thoughts are w.r.t. the -nosymbolstrip and
its ability to change the outcome here, aside from timing/order-of-op
differences, etc.  I assume you asked because you have an idea where the
failure might be.

(Just FYI, since submission I am now on:)

Version: (Indie Edition)
Hash: bbf3ac6
Build date: 2014-08-12 14:15:21-0400
Comment 4 Rolf Bjarne Kvinge [MSFT] 2014-09-09 12:13:26 UTC
-nosymbolstrip might fix EntryPointNotFoundExceptions, but I can't see how those can be random in the first place.

Could you share your project with us so that we can have a deeper look? That would most certainly be the fastest way to figure out what's going on.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2014-09-09 12:39:00 UTC
Can you provide device logs (from Xamarin Studio's View -> Pads -> iOS Device Log) and crash reports (from Xcode's Organizer)? That could also help us give you any clues.
Comment 7 Sebastien Pouliot 2016-05-25 00:50:28 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!