On 11/08/2013 09:10 PM, Dr. David Alan Gilbert wrote:
> * Denys Vlasenko ([email protected]) wrote:
>> On 11/06/2013 08:55 PM, Dr. David Alan Gilbert wrote:
>>> Hi,
>>> 'trinity' generated an io_submit call with a ludicrous large
>>> 'nr' of requests, the result being strace sat there just printing out
>>> {...}, for nearly ever since the data didn't exist.
>>>
>>> Is the right thing to 'break' rather than 'continue' if either
>>> of the umove calls fail? The alternative way is to break
>>> if the iocbs read fails but allow individualy broken iocb reads.
>>> I'm not sure which is more sane - you could have a real call
>>> that fails for another reason before hitting the bad iocb.
>>
>> Please try attached patch.
>
> Thanks, hmm it's surviving but I'm not sure it's giving the
> expected output in all cases; most of them look believable, but:
>
> 5347 io_submit(18446744073709551615, 127, {0xffffffff81000000}) = -1 EFAULT
> (Bad address)
>
> What's happened to that one - my reading of your patch would be that it
> would print an address without the {}'s if it failed on the iocbs read,
> so why is there only one entry?
It *is* failure to read iocbs[0]. Success (with subsequent failure
to read iocbs[0][0]) would look like this:
io_submit(18446744073709551615, 127, {{0xffffffsomehex}, ... })
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel
