On Wed, Feb 08, 2006 at 09:41:47PM +0100, Joris Huizer wrote:
Andreas Mohr wrote:
May I suggest that this is caused by a memory "allocation" of a pointer variable instead of a memory size variable? Pointers (memory addresses) usually are in the 0x40XXXXXX or 0x08XXXXXX range, so if you take those values as amount of memory to allocate...
IOW, perhaps there is a function parameter count mismatch in .spec files or some other random stack trashing that leads to such high memory allocation due to accessing the wrong variable.
You should probably try a ulimit -S -m 128000000 , that will most likely kill the process then when everything goes haywire, thus supporting my theory at least halfway.
Andreas Mohr
indeed the program got killed... at least it's a memory problem (maybe it was not the best situation, but I was logged in at a console and some output on running out of memory was written there) I don't really know what to look for, but as far as I see there isn't much interesting in the log, just a few fixme's that are repeated lots of times, and then these critical section timeouts:
end of the log (hopefully the relevant part) :
[lots of stubby sound APIs]
I'd thus do an educated strong guess that this is due to an issue in the sound parts. I think you should use additional tracing for all memory channels (WINEDEBUG=+local,+global,+virtual,+ntdll,+????) and check whether there's something grossly abnormal right before the program gets killed. If there is something, then it should be dead easy to figure out the remaining stuff with some further traces.
But those locking issues certainly seem troublesome, too...
Andreas