Mac App Store rejection for attempting to access /dev/shm

Oh Bum, I submitted this to apple 2 days ago, so looks like I've got another rejection on the way then!

 

Does anyone know if 3.5.5 fixes this problem? it wasn't mentioned in the release docs. Well not that I could see.

 

Yeah it didnt say so I assume it wasnt. The problem is we wont even know if it works for another 2 weeks because how long the review time takes.

 

Unfortunately they also don't list it under "known issues."

 

Any word from Unity on this?

 

it seems that no one from unity has made a comment on the subject, lets just wait and hope for the best

 

Guys, I just asked unity and got a reply. They say they think it is fixed in 3.5.5, so go ahead and resubmit.

 

/dev/shm is a Linux reinvent the wheel kind of thing. It looks like these 3.5.x incremental updates are including core Unity 4.0 features for compatibility testing.

 

Okay great but I dont see why they didnt say that in the release notes.

 

Make sure you backup your project before upgrading...
There seems to be a regression with the IOS builds. I had an IOS app work great with 3.5.4 and had a routine that takes a snapshot of the screen, now the screen comes back blank. I need more time to dig into it, but just a heads-up.

 

Not fixed... 3.5.5

08:41:06.873740 PAGE_IN_FILE A=0x00c9f000 0.000003 iLudo.6094
08:41:06.873745 PAGE_IN_FILE A=0x00d11000 0.000003 iLudo.6094
08:41:06.873750 PAGE_IN_FILE A=0x00d19000 0.000003 iLudo.6094
08:41:06.873751 getdirentries64 F=13 B=0xfe4 0.002195 W MacKeeper Helper.5160
08:41:06.873793 open [ 2] (R_____) /dev/shm 0.000041 iLudo.6094
08:41:06.873805 RdData[asyncP] D=0x0e649728 B=0x1000 /dev/disk0s2 0.000659 W mds.547
08:41:06.873895 pread F=23 B=0x14 O=0x033b1000 0.000767 W mds.547
08:41:06.874187 ftruncate F=8 O=0x00001000 0.000003 iLudo.6094
08:41:06.874193 mmap F=8 A=0x015f7000 O=0x00000000 B=0x1000 <READ|WRITE> 0.000005 iLudo.6094
08:41:06.874195 close F=8 0.000002 iLudo.6094
0

 

I am also getting my Mac App Store update rejected due to '/dev/shm' access.

Please fix promptly.

My eyeballs are peeled waiting for a update to resolve this issue.

 

Yes, the fix should be in, it just missed the release notes
Please let us know if you receive any news from submission service.

 

Are you sure your Unity is 3.5.5f2, not the f1?

 

On mobiles, Texture2D.ReadPixels implementation was changed to call glReadPixels only inside drawing. So if you call it from Update it will be deferred to the end of the current frame (Alongside Apply if you use it). Please, make note, that if you have some code that deals with screen copy made this way it won’t work in Update as the copy wasn’t made at this point, so you need to defer it too. The easiest way would be to use Camera’s OnPostRender to grab copy, or coroutine to delay processing to the next update.

 

Unfortunately I can confirm that. We are investigating what went wrong.

 

This is not good. Needless to say, could Unity please confirm this bug is fixed before a build is made available to the public?

Not to overload this thread, but there seems to be a regression made on IOS with 3.5.5f2. The code below worked fine on 3.4.5f1 on IOS, but now on IOS, it generates a blank black screen in the output.png file. However, in the 3.5.5f2 editor, the code worked fine and captured the actual screen:-

Code (csharp):

1.  
2. void OnGUI()
3.     {
4.         if( GUI.Button( new Rect( 0,0,50,50), "*" ) )
5.         {
6.              StartCoroutine(TakeScreenShot());
7.         }
8.     }
9.    
10. public IEnumerator TakeScreenShot()
11.     {
12.         int screenWidth;
13.         int screenHeight;
14.         Texture2D screenShotImage;
15.         string screenShotFile;
16.         bool fileSaved;
17.         byte[] bytes;
18.            
19.         screenShotFile = System.IO.Path.Combine( Application.persistentDataPath, "output.png" ) ;
20.        
21.         screenShotImage = new Texture2D( 0, 0, TextureFormat.RGB24, false );
22.  
23.         screenWidth = Screen.width;
24.         screenHeight = Screen.height;
25.         screenShotImage.Resize( screenWidth, screenHeight );
26.         screenShotImage.ReadPixels( new Rect(0,0,screenWidth,screenHeight), 0, 0 );
27.          
28.          
29.         screenShotImage.Apply();
30.         bytes = screenShotImage.EncodeToPNG();
31.         if ( File.Exists( screenShotFile ) ) {
32.             File.Delete( screenShotFile );
33.         }
34.         File.WriteAllBytes( screenShotFile, bytes );
35.         fileSaved = false;
36.         while ( !fileSaved ) {
37.             if ( File.Exists( screenShotFile ) ) {
38.                 fileSaved = true;
39.                 yield return null;
40.             }
41.         }
42.     }
43.    

 

Please take one more look at 3.5.5 release notes (http://unity3d.com/unity/whats-new/unity-3.5.5). It includes known issues section, which describes what was changed and how your code needs to be changed to conform new behavior of ReadPixels. Also ReadPixels documentation was updated accordingly : http://docs.unity3d.com/Documentation/ScriptReference/Texture2D.ReadPixels.html . Unfortunately this change was necessary to keep things working on upcoming iOS version.

 

Thank you very much for your prompt reply Mantas. " yield return null;" before "screenShotImage.Apply()" fixed the problem of blank screen capture.

Looking forward for the MAC "/dev/shm" fix.

 

Despite the previous posts from other users stating the problem didn't get fixed... our app TiamatHD

DID GET APPROVED (and should appear in the Mac App Store within 24 hours)

Please note it was previously denied for the "attempting to access /dev/shm" problem.
Please note also that I did nothing different, except this build was made with 3.5.5

I submitted it last night, and woke up to find it had already gone into review.

Since it was previously decline on account of the /dev/shm problem, I would think the reviewer would check for that preexisting condition.

Maybe we just got lucky?

At any rate, I figured I'd share.

 

Interesting, I was holding off on resubmitting as Mantas suggested '/dev/shm/' access was still a problem with 3.5.5

"Unfortunately I can confirm that. We are investigating what went wrong"

 

Which is why I figured I'd let everyone here know.
Again, it might have been a fluke where we just got lucky. But if I were you, I'd still re-submit; the worst that can happen is your app being declined again (status quo).

 

I just checked Tiamat HD and it is accessing /dev/shm :

Code (csharp):

1.  
2. 15:53:30.725752  open                   [  2] (R_____)  /dev/shm
3.                           0.000034   Tiamat HD.2654833
4.  

So it is either random luck or App Store checks were silently relaxed.

 

Yikes.
I guess time will tell.
I sent you a private message, Mantas.

 

Hey guys another thing I would like to complain about is why doesnt unity generate the proper info.plist, I have to go in there every time and chagne the garbage data,

Also create the icns file (why doesnt this happen automatically

We also have to create an entitlement file sign that.
And the same file is also not getting signed.

I have to go through 4 different threads to do it, I guess its okay but I would like for it to just work like the IOS version and not have to dig through various threads.
http://forum.unity3d.com/threads/71340-Submit-Unity-games-to-the-Mac-App-Store!
http://answers.unity3d.com/questions/140515/icon-in-build.html
http://forum.unity3d.com/threads/10...dbox-unity-OSX-stand-alones-for-mac-app-store
http://forum.unity3d.com/threads/132967-Problem-about-sandboxing-my-apps

 

I'll second this request. I've lost count of the number of times I've submitted an app and then realised I'd forgotten a vital step.

 

I'll third that. Doesn't seem like a big amount of work to integrate that seeing as I've pretty much done it myself already. I guess you have to ensure that if the Mac App Store submission process changes dramatically then it needs to be open enough for us to address any potential issues that might arise.

 

Unity 3.5.5f3 was just released - does it fix /dev/shm access?

 

Yes, it is expected to fix that problem.

(Fingers crossed)

 

HI Guys, I resubmitted my game compiled on 3.5.5.f2 and it just passed today! Yipee.

Mantas, Unity just told be an update was available (pc) f3. I downloaded it and instaled it, but when I now run unity it still says I have f2.
Plus the new version nag appears again. Did you update the rev number on the release?

Mantas, also a big thank you to yourself for coming on the forum and keeping us up to date.

 

on my side it says f3, im on osx..

lets hope this build fixes the problems

 

There was a glitch in web cache system. Those who got this problem should:
a) unmount Unity installer image in Finder
b) re-download installer
c) reinstall Unity with newly downloaded installer

 

btw, our app with /dev/shm fix just got approved on App Store.

 

i resubmit 4 times.... using 3.5.5 f2 and below
4 times reject ......

two errors ...

error 1 . : /dev/shm ( maybe fix with unity 3.5.6 )
error 2 . : my entitlements configuration ..... picture below

please help me how shoud be configurated....


entitlements picture click here
http://www.elsalvadorguia.com/error3b.jpg

 

Try 3.5.6 my app just passed using it after failing with the /dev/shm error. My entitlements file looks like this:

Code (csharp):

1. <?xml version="1.0" encoding="UTF-8"?>
2. <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
3. <plist version="1.0">
4. <dict>
5.     <key>com.apple.security.app-sandbox</key>
6.     <true/>
7.     <key>com.apple.security.network.client</key>
8.     <true/>
9. </dict>
10. </plist>

 

thanks ... now is waiting for review...
i will make a video or tutorial... steep by steep .... if app is relese to sale.
i promiss !!!

thanks for any help !

 

Hey guys,

Is it possible there is a regression in Unity 2017.3? My Mac app just got rejected by the same reason:

Your application accesses the following location(s): '/dev/shm'

Thanks,
Tom

 

@Mantas-Puida Can you comment on this please?

 

Please submit a bugreport with details about your application and I will forward it to Desktop team.

 

@Mantas-Puida I have created an issue here:
https://fogbugz.unity3d.com/default.asp?1035654_q3sdc4pcgifq6oa6

Can you please forward it to the proper team?
Thanks

 

Done

 

According to the team, this issue might be brought by Mono runtime upgrade. They are working on a fix.
There is workaround possible by setting MONO_DISABLE_SHARED_AREA env variable to 1, before application launches.
For Mac App Store apps it might be tricky, but seems to be possible via Info.plist of your app. Just add there LSEnvironment dictionary(https://developer.apple.com/library...Keys.html#//apple_ref/doc/uid/20001431-106825) with that key:
<key>LSEnvironment</key>
<dict>
<key>MONO_DISABLE_SHARED_AREA</key>
<string>1</string>
</dict>

 

Hi there! @Mantas-Puida I just wanted to let you know that your fix must have worked - my app was finally approved into mac app store.

Thank you!

 

Thank you. My app got approved after adding above key.