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
Building big app in Visual C++ in Wine uses too many file ha
Building big app in Visual C++ in Wine uses too many file ha
Dan Kegel wrote:
can only open 256 handles before the system says EMFILE.
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
If you think that's low, on Mac OS X the default FD limit is 256! YouThe 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.
can only open 256 handles before the system says EMFILE.
Anyway, recall that all loading of shared libraries is done by ld.so inNo idea what those ld.so errors are, though.
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