Dan Kegel
2010-Jan-27 22:01 UTC
[Wine] Building big app in Visual C++ in Wine uses too many file handles in wineserver, wheee....
Building chromium in visual c++ 2005 on current wine on an 8 core monster machine, I got some random errors: Inconsistency detected by ld.so: dl-open.c: 256: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state =RT_CONSISTENT' failed! Inconsistency detected by ld.so: dl-open.c: 256: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state =RT_CONSISTENT' failed! wine: Invalid handle wine client error:0: init_thread failed with status c000011f wine: Invalid handle wine: Module not found Inconsistency detected by ld.so: dl-open.c: 256: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state =RT_CONSISTENT' failed! c000011f is STATUS_TOO_MANY_OPENED_FILES There were corresponding errors in the devenv log saying that perfectly good files didn't exist, so I imagine it was just an open failure. The wineserver is process 1247, and sure enough, ls /proc/1247 shows file descriptors as high as 973 in use. The default ulimit -n is 1024, so it probably briefly exceeded that. I guess I'll bump up ulimit -n for the wine session and keep an eye out for leaks... (For those who haven't done this, one way is sudo bash ulimit -n 5000 su dank That gets you a normal shell with the raised file descriptor limit.) I didn't see any of this when running on a slower 4 core machine with source from two days ago, so I'll bet it's just the extra load. No idea what those ld.so errors are, though. - Dan
Charles Davis
2010-Jan-27 23:28 UTC
[Wine] Building big app in Visual C++ in Wine uses too many file handles in wineserver, wheee....
Dan Kegel wrote:> The wineserver is process 1247, and sure enough, ls /proc/1247 shows > file descriptors as high as 973 in use. The default ulimit -n is 1024, > so it probably briefly exceeded that.If you think that's low, on Mac OS X the default FD limit is 256! You can only open 256 handles before the system says EMFILE.> No idea what those ld.so errors are, though.Anyway, recall that all loading of shared libraries is done by ld.so in userland. I'd venture a guess that ld.so opens the file, then tries to mmap(2) the file into memory. Key words: "opens the file". It, too is running out of FDs. That's probably why you're getting the dlopen(3)-related error. Chip