Bug #1157

Missing Textures - Too many open files

Added by velogfx over 4 years ago. Updated over 3 years ago.

Status:Closed Start date:11/03/2010
Priority:Normal Due date:
Assignee:rti % Done:

0%
Category:OS: Mac
Target version:Version 0.9.0

Description

As you can see on the screen above, there are missing Textures on some models:

Missing Textures

mac_build_alpha_missing_textures.png - Missing Textures (690.7 kB) velogfx, 11/03/2010 08:05 pm

Screen_shot_2011-06-06_at_10.01.12.jpg (770.3 kB) rti, 06/06/2011 10:07 am

client.log (524.8 kB) rti, 06/06/2011 10:07 am

Bildschirmfoto_2011-06-07_um_11.54.09.png (432.4 kB) velogfx, 06/07/2011 12:53 pm

History

#1 Updated by velogfx over 4 years ago

it's an random issue, after restarting the client some textures are back and other missing.

#2 Updated by rti about 4 years ago

indeed, seems very random.
seeing this the first time in 7 month :(

#3 Updated by rti about 4 years ago

That explains it (from client.log):

2011/06/06 10:09:36 WRN 818417664 <Unknown> big_file.cpp 436 getFile : bnp: can't fopen big file '/Users/rti/Code/ryzom-core/ryzom-core-repository/code/build-static-release/bin/ryzom_client.app/Contents/Resources/data/characters_maps_ma_hof_cheveux_hr.bnp' error 24 'Too many open files'

#4 Updated by rti about 4 years ago

  • Subject changed from Mac - Alpha Build - Missing Textures to Missing Textures - Too many open files
  • Category set to OS: Mac

#5 Updated by rti about 4 years ago

I am currently observing that linking OpenAL soft (see #1314 for more information) makes this problem pop up on my machine.
Client binaries linked with Apple's OpenAL.framework have no problem with open file limitations.

@velogfx: This ticket is quite old. Did you see this problem still in recent client builds? Does this problem occur with the newest OpenAL soft client build?

#6 Updated by kervala about 4 years ago

So OpenAL crash could be related to files not being able to be opened ?

#7 Updated by rti about 4 years ago

@kervala: Not sure.
As velogfx confirmed, the file limit problem first occurred with the OpenAL soft build again. Long time before it was gone (probably due to #1003). On the other hand, the two known OpenAL problems (#1116 and #1298) did not ocurre with the OpenAL soft build... :)

#8 Updated by velogfx about 4 years ago

rti wrote:

I am currently observing that linking OpenAL soft (see #1314 for more information) makes this problem pop up on my machine.
Client binaries linked with Apple's OpenAL.framework have no problem with open file limitations.

@velogfx: This ticket is quite old. Did you see this problem still in recent client builds? Does this problem occur with the newest OpenAL soft client build?

hi, yes still get them in the latest OpenAL version.

#9 Updated by velogfx about 4 years ago

here is the pic

#10 Updated by rti about 4 years ago

Ok. The problem really reoccured due to the linking of OpenAL soft.

Ace already fought a very similar problem month ago.
http://stackoverflow.com/questions/3166783/how-to-increase-the-limit-of-maximum-open-files-in-c-on-mac-os-x/3214064#3214064

Bottom line:
Calls to setrlimit (to increase the number of allowed file descriptors in a process) only work if the process did not call printf already.

Now, OpenAL soft is doing quite a lot of stuff at static initialization time (see Alc.c:471 alc_init(), __attribute__ ((constructor))). A part of this function has the same effect as calling printf. setrlimit does not work anymore. Ryzom client is calling setrlimit later on, in main().

#11 Updated by rti about 4 years ago

  • Status changed from Validated to Assigned
  • Assignee set to rti
  • Target version set to Version 0.9.0

BTW, this problem should only appear in WITH_STATIC_DRIVERS builds. Else, the OpenAL lib is loaded at a later point in time. So the problem should be gone then.

Anyway, since this problem is strongly related to the usage of OpenAL soft on Mac OS X, i would like to mark this issue as resolved and track further progress in Feature #1314 - OpenAL environment effects on Mac OS X.

Setting it on "assigned" now because redmine does not allow me to set it to "resolved" directly.

#12 Updated by rti about 4 years ago

  • Status changed from Assigned to Resolved

#13 Updated by sfb over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF