A little update.

I updated to libcurl 7.16.2.

I still have the corruption problem, but it seems to happen less often
(1% instead of 5%, though it's too few testing to trust this fully).

What I found really curious is that there is some kind of pattern
repeating in the corrupted files ( like c00c 0100 0010 see below )

FILE 23/300

17089,17091c17089,17091
< 0042c10 666a 07bb 8dee 719a c672 3cb9 cb7a 3e5f
< 0042c20 d556 481f b6ba 0c2d a546 6ee6 4a4d 20fd
< 0042c30 e88c 0fce 1c1e b740 9863 99ea c7f9 1acd

> 0042c10 666a 07bb 8dee 719a c672 0200 0020 0938
> 0042c20 c4b7 9f40 c5f6 0000 0000 3300 c61c 7ed4
> 0042c30 c00c 0100 0010 0200 0020 99ea c7f9 1acd

17095,17097c17095,17097
< 0042c70 4733 d0a5 0c62 09f4 8ad0 c79d 95d1 e89b
< 0042c80 91c2 d832 80f2 46dd 47c0 81ca 913a 8e91
< 0042c90 e64a c9ce b450 2431 3b86 a580 f65b f4d8

> 0042c70 4733 d0a5 0c62 09f4 8ad0 0000 0000 3300
> 0042c80 c61c 7ed4 c00c 0100 0010 0200 0020 f1a0
> 0042c90 c298 0000 0000 0000 0000 a580 f65b f4d8

FILE 214/300

23204,23206c23204,23206
< 005aa40 92ac fd23 50a1 2928 5aed 4ded 5e66 9fd2
< 005aa50 e356 270e ea89 4e5a f9ad 0d8b 94c7 95bc
< 005aa60 c905 e649 7926 e549 b134 c227 dcb5 c59d

> 005aa40 92ac fd23 50a1 2928 5aed 4ded 5e66 0100
> 005aa50 0010 0200 0020 0940 c4b7 23e0 c49f 0000
> 005aa60 0000 3300 c61c 7ed4 c00c 0100 0010 c59d

FILE 247/300

10972,10973c10972,10973
< 002adc0 cd86 9a81 4439 0e52 9243 edaa d853 3f82
< 002add0 66cc 8f6e 312c 56fd 26de 706b cbbf 031a

> 002adc0 cd86 9a81 4439 0e52 9243 7ed4 c00c 0100
> 002add0 0010 0200 0020 3820 c38c 706b cbbf 031a

Just wondering, would it be possible that having a lot of i/o
operations at the same time would cause this kind of behavior ? I am
logging debug on a file at the same time, writing to pipes etc...

Regards,

Nicolas

On 5/16/07, Linus Nielsen Feltzing <linus_at_haxx.se> wrote:
> Nicolas Martin wrote:
> > 2957,2959c2957,2959
> > 000b8d0 4160 6e7f 1a99 9b03 7223 d368 11ec 23f3
> > 000b8e0 4619 32f9 a434 6dd4 f9b6 81e1 a203 4bc2
> > 000b8f0 e04e 578a c3df 4812 906a afbe d3ff fee5
> > ---
> > 000b8d0 4160 6e7f 1a99 9b03 7223 0100 0010 0200
> > 000b8e0 0020 d940 c5d2 13e0 c44f 0000 0000 3300
> > 000b8f0 c61c 7ed4 c00c 0100 0010 afbe d3ff fee5
> >
> > I dumped the data received in the write callback (*ptr) and noticed
> > that this data is already faulty (i.e it's not a problem of i/o disk).
> >
> > The software compiled for a i386 platform never yields this problem,
> > hence it is a problem on the platform side.
>
> Since it is exactly 32 bytes that are changed, I would suspect a cache
> problem. Are the cache lines by any chance 32 bytes on that platform?
>
> Linus
>
Received on 2007-05-16