Comment 1:

Can you please run the test by hand, and then
after it fails, run strace -f 5.out ?

Owner changed to @rsc.

Status changed to Accepted.

Comment 2:

axentraserver(~/go/src/pkg/os) % strace -f ./5.out 2>&1 | grep -C2 ftruncate
[pid  4856] write(5, "hello, world\n", 13) = 13
[pid  4856] fstat64(5, {st_mode=S_IFREG|0600, st_size=13, ...}) = 0
[pid  4856] ftruncate64(5, 10)          = -1 EFBIG (File too large)
[pid  4856] fstat64(5, {st_mode=S_IFREG|0600, st_size=13, ...}) = 0
[pid  4856] ftruncate64(5, 1024)        = -1 EFBIG (File too large)
[pid  4856] fstat64(5, {st_mode=S_IFREG|0600, st_size=13, ...}) = 0
[pid  4856] ftruncate64(5, 0)           = -1 EFBIG (File too large)
[pid  4856] fstat64(5, {st_mode=S_IFREG|0600, st_size=13, ...}) = 0
[pid  4856] write(5, "surprise!", 9)    = 9
Full strace attached.

Attachments:

1. issue1714-strace.txt (65285 bytes)

Comment 3:

adg was good enough to knock up some test code in C to verify the libc behavior on this
host
axentraserver(~/devel) % cat truncate.c 
#include <stdio.h>
#include <stdlib.h>
int
main(int argc, char** argv)
{
       char* str = "hello, world\n";
       int fp;
       if ((fp = creat("/tmp/test.txt", 0666)) < 0) {
               exit(1);
       }
       write(fp, str, 13);
       if (ftruncate64(fp, __off64_t(10)) != 0) {
               printf("error truncating\n");
               exit(1);
       }
       close(fp);
}
axentraserver(~/devel) % strace ./a.out 2>&1 | tail -n5
creat("/tmp/test.txt", 0666)            = 3
write(3, "hello, world\n", 13)          = 13
ftruncate64(3, 10)                      = 0
close(3)                                = 0
exit_group(0)                           = ?
axentraserver(~/devel) % stat /tmp/test.txt 
  File: `/tmp/test.txt'
  Size: 10          Blocks: 8          IO Block: 4096   regular file
Device: 811h/2065d  Inode: 43          Links: 1
Access: (0644/-rw-r--r--)  Uid: (  501/     dfc)   Gid: (  503/     dfc)
Access: 2011-04-19 14:48:13.000000000 +1000
Modify: 2011-04-19 14:53:14.000000000 +1000
Change: 2011-04-19 14:53:14.000000000 +1000

Comment 4:

Okay, so even though strace cannot see the difference
(it too is probably buggy) it looks like the ftruncate64 that
Go is issuing is not the same as the ftruncate64 that C is
issuing.
Dave, do gdb breakpoints work on your platform?
If so, please try
$ gdb a.out
(gdb) b close
(gdb) r
... stops at close breakpoint
(gdb) disas ftruncate64
... if that fails, run "x/100i ftruncate64" instead.
(gdb) disas main
... if that fails, run "x/100i main" instead.
and let us know what the assembly says for both
functions.
If gdb breakpoints do not work (they don't on some
ARM hardware I have), you can make your own
"breakpoint" by recompiling the program with
    *(int*)0 = 0;
just before the close(fp) line.
It's important to run the binary (the r command) before
the disassembly, because often the dynamic linker does
not set up the bindings for called functions until they
have been called once.
If the assembly listing for ftruncate64 is super short
(just 3-4 instructions) then try recompiling with gcc -static.
Thanks.
Russ

Comment 5:

Hi Russ, thanks for your suggestions.
Breakpoint 1, 0x40015fb0 in close () from /lib/ld-linux.so.3
(gdb) disas ftruncate64
Dump of assembler code for function ftruncate64:
0x000083a0 <ftruncate64+0>:   add r12, pc, #0 ; 0x0
0x000083a4 <ftruncate64+4>:   add r12, r12, #32768    ; 0x8000
0x000083a8 <ftruncate64+8>:   ldr pc, [r12, #828]!
End of assembler dump.
(gdb)  disas main
Dump of assembler code for function main:
0x00008460 <main+0>:  push    {r4, r11, lr}
0x00008464 <main+4>:  add r11, sp, #8 ; 0x8
0x00008468 <main+8>:  sub sp, sp, #28 ; 0x1c
0x0000846c <main+12>: str r0, [r11, #-32]
0x00008470 <main+16>: str r1, [r11, #-36]
0x00008474 <main+20>: ldr r3, [pc, #132]  ; 0x8500 <main+160>
0x00008478 <main+24>: str r3, [r11, #-28]
0x0000847c <main+28>: ldr r0, [pc, #128]  ; 0x8504 <main+164>
0x00008480 <main+32>: ldr r1, [pc, #128]  ; 0x8508 <main+168>
0x00008484 <main+36>: bl  0x834c <creat>
0x00008488 <main+40>: mov r3, r0
0x0000848c <main+44>: str r3, [r11, #-24]
0x00008490 <main+48>: ldr r3, [r11, #-24]
0x00008494 <main+52>: cmp r3, #0  ; 0x0
0x00008498 <main+56>: bge 0x84a4 <main+68>
0x0000849c <main+60>: mov r0, #1  ; 0x1
0x000084a0 <main+64>: bl  0x83ac <exit>
0x000084a4 <main+68>: ldr r0, [r11, #-24]
0x000084a8 <main+72>: ldr r1, [r11, #-28]
0x000084ac <main+76>: mov r2, #13 ; 0xd
0x000084b0 <main+80>: bl  0x837c <write>
0x000084b4 <main+84>: mov r3, #10 ; 0xa
---Type <return> to continue, or q <return> to quit--- 
0x000084b8 <main+88>: mov r4, #0  ; 0x0
0x000084bc <main+92>: str r3, [r11, #-20]
0x000084c0 <main+96>: str r4, [r11, #-16]
0x000084c4 <main+100>:    ldr r0, [r11, #-24]
0x000084c8 <main+104>:    sub r2, r11, #20    ; 0x14
0x000084cc <main+108>:    ldm r2, {r2, r3}
0x000084d0 <main+112>:    bl  0x83a0 <ftruncate64>
0x000084d4 <main+116>:    mov r3, r0
0x000084d8 <main+120>:    cmp r3, #0  ; 0x0
0x000084dc <main+124>:    beq 0x84f0 <main+144>
0x000084e0 <main+128>:    ldr r0, [pc, #36]   ; 0x850c <main+172>
0x000084e4 <main+132>:    bl  0x8394 <puts>
0x000084e8 <main+136>:    mov r0, #1  ; 0x1
0x000084ec <main+140>:    bl  0x83ac <exit>
0x000084f0 <main+144>:    ldr r0, [r11, #-24]
0x000084f4 <main+148>:    bl  0x8388 <close>
0x000084f8 <main+152>:    sub sp, r11, #8 ; 0x8
0x000084fc <main+156>:    pop {r4, r11, pc}
0x00008500 <main+160>:    andeq   r8, r0, r8, lsl #11
0x00008504 <main+164>:    muleq   r0, r8, r5
0x00008508 <main+168>:    strheq  r0, [r0], -r6
0x0000850c <main+172>:    andeq   r8, r0, r8, lsr #11
End of assembler dump.
I'll recompile truncate.c again with -static but it'll take me a little time as this
platform is pretty cut down and currently complaining 
axentraserver(~/devel) % gcc -static truncate.c 
/opt/lib/gcc/arm-none-linux-gnueabi/4.2.3/../../../../arm-none-linux-gnueabi/bin/ld:
cannot find -lc
as there is no libc.a, on libc.so on this host.

Comment 6:

Hi Russ,
I recompiled truncate.c statically on inside qemu host on another machine using images
found here
http://people.debian.org/~aurel32/qemu/armel/
The resulting binary works as expected on my arm5 system, here is the output from gdb
axentraserver(~/devel) % gdb ./truncate-static 
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-none-linux-gnueabi"...
(gdb) b close
Breakpoint 1 at 0x11d30
(gdb) r
Starting program: /home/dfc/devel/truncate-static 
Breakpoint 1, 0x00011d30 in close ()
Current language:  auto; currently asm
(gdb) disas ftruncate64
Dump of assembler code for function ftruncate64:
0x00012128 <ftruncate64+0>:   push    {r7, lr}
0x0001212c <ftruncate64+4>:   mov r1, #0  ; 0x0
0x00012130 <ftruncate64+8>:   mov r7, #194    ; 0xc2
0x00012134 <ftruncate64+12>:  svc 0x00000000
0x00012138 <ftruncate64+16>:  cmn r0, #4096   ; 0x1000
0x0001213c <ftruncate64+20>:  mov r2, r0
0x00012140 <ftruncate64+24>:  movls   r0, r0
0x00012144 <ftruncate64+28>:  bhi 0x12150 <ftruncate64+40>
0x00012148 <ftruncate64+32>:  pop {r7, lr}
0x0001214c <ftruncate64+36>:  bx  lr
0x00012150 <ftruncate64+40>:  ldr r3, [pc, #20]   ; 0x1216c <ftruncate64+68>
0x00012154 <ftruncate64+44>:  bl  0x8b50 <__aeabi_read_tp>
0x00012158 <ftruncate64+48>:  ldr r3, [pc, r3]
0x0001215c <ftruncate64+52>:  rsb r2, r2, #0  ; 0x0
0x00012160 <ftruncate64+56>:  str r2, [r0, r3]
0x00012164 <ftruncate64+60>:  mvn r0, #0  ; 0x0
0x00012168 <ftruncate64+64>:  b   0x12148 <ftruncate64+32>
0x0001216c <ftruncate64+68>:  andeq   pc, r6, r0, ror #7
End of assembler dump.
(gdb) disas main
Dump of assembler code for function main:
0x00008238 <main+0>:  mov r12, sp
0x0000823c <main+4>:  push    {r4, r11, r12, lr, pc}
0x00008240 <main+8>:  sub r11, r12, #4    ; 0x4
0x00008244 <main+12>: sub sp, sp, #36 ; 0x24
0x00008248 <main+16>: str r0, [r11, #-40]
0x0000824c <main+20>: str r1, [r11, #-44]
0x00008250 <main+24>: ldr r3, [pc, #136]  ; 0x82e0 <main+168>
0x00008254 <main+28>: str r3, [r11, #-36]
0x00008258 <main+32>: ldr r0, [pc, #132]  ; 0x82e4 <main+172>
0x0000825c <main+36>: ldr r1, [pc, #132]  ; 0x82e8 <main+176>
0x00008260 <main+40>: bl  0x12020 <creat>
0x00008264 <main+44>: mov r3, r0
0x00008268 <main+48>: str r3, [r11, #-32]
0x0000826c <main+52>: ldr r3, [r11, #-32]
0x00008270 <main+56>: cmp r3, #0  ; 0x0
0x00008274 <main+60>: bge 0x8280 <main+72>
0x00008278 <main+64>: mov r0, #1  ; 0x1
0x0000827c <main+68>: bl  0x8de4 <exit>
0x00008280 <main+72>: ldr r0, [r11, #-32]
0x00008284 <main+76>: ldr r1, [r11, #-36]
0x00008288 <main+80>: mov r2, #13 ; 0xd
0x0000828c <main+84>: bl  0x11e50 <write>
0x00008290 <main+88>: mov r3, #10 ; 0xa
0x00008294 <main+92>: mov r4, #0  ; 0x0
0x00008298 <main+96>: str r3, [r11, #-28]
0x0000829c <main+100>:    str r4, [r11, #-24]
0x000082a0 <main+104>:    ldr r0, [r11, #-32]
0x000082a4 <main+108>:    sub r2, r11, #28    ; 0x1c
0x000082a8 <main+112>:    ldm r2, {r2, r3}
0x000082ac <main+116>:    bl  0x12128 <ftruncate64>
0x000082b0 <main+120>:    mov r3, r0
0x000082b4 <main+124>:    cmp r3, #0  ; 0x0
0x000082b8 <main+128>:    beq 0x82cc <main+148>
0x000082bc <main+132>:    ldr r0, [pc, #40]   ; 0x82ec <main+180>
0x000082c0 <main+136>:    bl  0x9100 <puts>
0x000082c4 <main+140>:    mov r0, #1  ; 0x1
0x000082c8 <main+144>:    bl  0x8de4 <exit>
0x000082cc <main+148>:    ldr r0, [r11, #-32]
0x000082d0 <main+152>:    bl  0x11d30 <close>
0x000082d4 <main+156>:    sub sp, r11, #16    ; 0x10
0x000082d8 <main+160>:    ldm sp, {r4, r11, sp, lr}
0x000082dc <main+164>:    bx  lr
0x000082e0 <main+168>:    muleq   r6, r12, r3
0x000082e4 <main+172>:    andeq   r4, r6, r12, lsr #7
0x000082e8 <main+176>:    strheq  r0, [r0], -r6
0x000082ec <main+180>:    strheq  r4, [r6], -r12
End of assembler dump.

Comment 7:

http://golang.org/cl/4441056

Comment 8:

This issue was closed by revision d586445.

Status changed to Fixed.