Bug 33419 - Setting the DYLD_* environment variable does not show any output
Summary: Setting the DYLD_* environment variable does not show any output
Status: CONFIRMED
Alias: None
Product: iOS
Classification: Xamarin
Component: Debugger ()
Version: XI 8.10
Hardware: PC Mac OS
: Normal normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-08-27 09:38 UTC by John Miller [MSFT]
Modified: 2015-08-27 11:03 UTC (History)
3 users (show)

Tags:
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 for Bug 33419 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description John Miller [MSFT] 2015-08-27 09:38:31 UTC
**Overview:**

   While trying to debug dynamic libraries on iOS, it's suggested to enable an environment variable for some diagnostic output: DYLD_LIBRARY_PATH

See https://developer.apple.com/library/ios/technotes/tn2239/_index.html#//apple_ref/doc/uid/DTS40010638-CH1-SUBSECTION21

Unfortunately, setting this in XS does not seem to output anything.

**Steps to Reproduce:**

   1. Set the variable in XS for an iOS project via the Project Options -> General menu
   2. The var is "DYLD_LIBRARY_PATH" and the value is 1. 
   3. Run the project on an iOS device in debug mode.

**Actual Results:**

   No output in the Application Output / Console or Device logs. 

**Expected Results:**

   Some output like this: 

CFLOG_FORCE_STDERR=YES
PATH=/usr/bin:/bin:/usr/sbin:/sbin
FBSClientLogging=0
LOGNAME=mobile
CLASSIC=0
CFFIXED_USER_HOME=/private/var/mobile/Containers/Data/Application/3AA4DF7E-727E-4212-A891-9636B40E800E
DYLD_LIBRARY_PATH=/usr/lib/system/introspection
__CF_USER_TEXT_ENCODING=0x1F5:0:0
HOME=/private/var/mobile/Containers/Data/Application/3AA4DF7E-727E-4212-A891-9636B40E800E
DYLD_INSERT_LIBRARIES=/Developer/usr/lib/libBacktraceRecording.dylib

**Build Date & Platform:**

   XI 8.10.4.46
   XS 5.9.5
Comment 1 Sebastien Pouliot 2015-08-27 09:48:52 UTC
DYLD_LIBRARY_PATH is not part of the document (link) you provided.

DYLD_LIBRARY_PATH is meant to accept path(s) not a number to help diagnosing issues.
Comment 2 Fraser Ruffelll 2015-08-27 09:50:32 UTC
Issue is seen with any of the variables defined in the documentation. Last one I tried was:

DYLD_PRINT_ENV 

which did not yield any output.
Comment 3 Sebastien Pouliot 2015-08-27 10:43:44 UTC
Quoted from the document:

> While these environment variables are implemented on iOS, many of them
> have limited utility because of the restricted environment on that system.

What it means is that:

1. Nearly all applications' code comes from the main executable - directly or from static libraries (Apple requirement for iOS, unless you use "user frameworks") and won't be loaded by the dynamic linker. IOW their output is generally* not helpful;

2. Most of those debugging environment variables needs to be set before the application starts. This is not what XS does (even if it "starts" the app, it's not the process that does so) so the environment variables are set very early in the application startup (but too late for dyld to help). IOW the application (and it's libraries) can initialize itself from the variables, but they won't change iOS behaviours.


It's technically possible (at least for the simulator) to set such variables* earlier but neither XS (or the iOS Simulator itself) expose a way to do it.

* that's something we need to develop XI itself (because we do load the iOS frameworks dynamically) but there has not been any need (or use case) where this has proven useful for customer code.

Please let us know if your issue does not fall within the #1 restriction.


Note: specifically for `DYLD_PRINT_ENV` you can do the same using `System.Environment` just before calling `UIApplication.Main` (or anytime later).
Comment 4 Fraser Ruffelll 2015-08-27 10:55:04 UTC
Thanks for the info.

The reason I was looking for this support was to debug issues that were causing the app to fail to launch. Our Xamarin.iOS application is using custom Cocoa Touch Frameworks deployed as dynamic libraries and the dynamic linker was unable to resolve the embedded frameworks, usually with an error like this:

dyld: Library not loaded: <snip> 
  Reason: image not found

This unfortunately means that the application does not execute Main(), and debugging from within the app is not possible.

I was able to resolve the issue by setting the install path on the frameworks and providing mtouch linker arguments to set rpath, but it took some trial and error. When I had the same issue in Xcode, setting these environment variables made the debugging process much faster.

Not knowing the implementation details of Xamarin's debugger process I just assumed the same could be done as via Xcode :) 

I do see the environment variables are set correctly via XS when the app runs, just no output. Thanks!
Comment 5 Sebastien Pouliot 2015-08-27 11:03:24 UTC
It makes sense, with user frameworks, to make those variables work then. We'll look into enabling their support in a future release.

Thanks for the details.