Simon Kelley <[email protected]> writes: > Ferenc Wagner wrote: > >> Simon Kelley <[email protected]> writes: >> >>> On 15/09/10 12:07, Ferenc Wagner wrote: >>> >>>> However, I also got a different crash with the original binary. I hope >>>> it's a different realisation of the same problem, can you confirm? >>> >>> I can't see any other reason for this problem, I'm pretty sure it's >>> down to heap corruption from an earlier double-free. >> >> It's a rather narrow chance, as I was running under electric fence... > > It was late..... I'll try again :-) > > At the point of the crash, 0xb7184f8c had already been freed and > therefore mapped out by efence. Hence when 0xb7184f8c gets deferenced > by memcpy, it segfaults. This is consistent with the known and fixed bug.
Yes, if the segfault comes from the first byte moved, not from a later out-of-range one, caused by the bogus value of "len". Why, I've still got the core, let's check... (gdb) x/i $eip 0xb7599d5a <memcpy+26>: movsw %ds:(%esi),%es:(%edi) (gdb) p/x $edi $1 = 0xb7184f8c You're right, it's the first access. > The value of "len" must be a optimisation artifact, there is no way that > add_extradata_opt() could generate that value. I've never seen such an artifact (pretty much nothing but a value being optimized out), but my C is admittedly rusty. (gdb) x $esp+0xc 0xbfda0e98: 0x0000000e So memcpy() was called for 14 bytes, nothing like that crazy number. >>>> I'm continuing testing the fix. It usually took me tens of minutes to >>>> reproduce the crash, but with the change it already survived more than >>>> an hour. Unfortunately, it isn't fully automatic (because of other bugs >>>> in other software). >>> >>> To trigger this bug, there needs to be a dhcp-script, obviously. But >>> also the rate of DHCP transactions needs to be fast enough and/or the >>> script needs to be slow enough so that a second DHCP transaction >>> happens on a lease before the first one has been sent to the >>> DHCP-script. This is pretty rare, hence no-one has seen this bug, as >>> far as I know, even though it has been lurking for some time (years). >> >> Well, this doesn't fully match my test setup, which contained a single >> netbooted Linux continuously rebooting in Qemu. The exotic part is that >> the PXE ROM used the network interface natively, while the Linux system >> with an added 802.1q tag. So a single lease was ping-ponging between >> two different subnets. > > How much work was you dhcp-script doing. It's nothing but a call to an SGE utility to add the new host to a hostlist. The script itself is nothing, and qconf shouldn't take long either. Occasionally it encounters a DNS problem (unable to resolve host, cf. other thread), but even that's fast, not some 5 sec timeout. > By coincidence I had another report of this bug yesterday which > triggered only when the DHCP transaction rate is high. Lucky you! :) -- Cheers, Feri.
