You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2008-08-04 09:14:08
- piotroxp
- Member
- Registered: 2008-08-04
- Posts: 66
LIBC PROBLEM - SIGSEGV in getc()
Hello.
I'm using arch krnl2.6.25 on a 2gb amd64-3200+ 320gb nforce4 machine. I'm using Gnome as my GUI. I'm also using gnu gcc bined with eclipse, I have JRE 6 installed. Freshest versions of libc/binutils installed also. No permission problems spotted.
Before updating libc, I've also had the problem, which is :
I recieve segmentation faults whenever I try to call getc() or its derivatives (fgetc, gets, fgets and so on). The filedescriptor is correctly bound to an example file. I've even written a short app in bare c to test whether it was something I've not included or overincluded. It turns out quite the same.
:
#include "stdio.h"
#include "stdlib.h"
typedef FILE* filedesc;
int main(){
int surg;
filedesc fl;
fl=fopen("test.txt","r");
if(fl == NULL){
printf("%s","arch rox!");
}else{
while((surg=getc(fl)) != EOF){
printf("%c",surg);
}
fclose(fl);
}(gdb) bt
Program received signal SIGSEGV, Segmentation fault.
0xb7e050f2 in getc () from /lib/libc.so.6
#0 0xb7e660f2 in getc () from /lib/libc.so.6
#1 0x0804845f in main () .file "test.c"
.section .debug_abbrev,"",@progbits
.Ldebug_abbrev0:
.section .debug_info,"",@progbits
.Ldebug_info0:
.section .debug_line,"",@progbits
.Ldebug_line0:
.text
.Ltext0:
.section .rodata
.LC0:
.string "r"
.LC1:
.string "test.txt"
.LC2:
.string "arch rox!"
.LC3:
.string "%s"
.text
.globl main
.type main, @function
main:
.LFB2:
.file 1 "test.c"
.loc 1 6 0
leal 4(%esp), %ecx
.LCFI0:
andl $-16, %esp
pushl -4(%ecx)
.LCFI1:
pushl %ebp
.LCFI2:
movl %esp, %ebp
.LCFI3:
pushl %ecx
.LCFI4:
subl $36, %esp
.LCFI5:
.loc 1 11 0
movl $.LC0, 4(%esp)
movl $.LC1, (%esp)
call fopen
movl %eax, -8(%ebp)
.loc 1 13 0
cmpl $0, -8(%ebp)
jne .L4
.loc 1 14 0
movl $.LC2, 4(%esp)
movl $.LC3, (%esp)
call printf
jmp .L7
.L5:
.loc 1 17 0
movl -12(%ebp), %eax
movl %eax, (%esp)
call putchar
.L4:
.loc 1 16 0
movl -8(%ebp), %eax
movl %eax, (%esp)
call _IO_getc
movl %eax, -12(%ebp)
cmpl $-1, -12(%ebp)
jne .L5
.loc 1 19 0
movl -8(%ebp), %eax
movl %eax, (%esp)
call fclose
.L7:
.loc 1 21 0
addl $36, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.LFE2:
.size main, .-main
.section .debug_frame,"",@progbits
.Lframe0:
.long .LECIE0-.LSCIE0
.LSCIE0:
.long 0xffffffff
.byte 0x1
.string ""
.uleb128 0x1
.sleb128 -4
.byte 0x8
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE0:
.LSFDE0:
.long .LEFDE0-.LASFDE0
.LASFDE0:
.long .Lframe0
.long .LFB2
.long .LFE2-.LFB2
.byte 0x4
.long .LCFI0-.LFB2
.byte 0xc
.uleb128 0x1
.uleb128 0x0
.byte 0x9
.uleb128 0x4
.uleb128 0x1
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x4
.long .LCFI2-.LCFI1
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI3-.LCFI2
.byte 0xd
.uleb128 0x5
.byte 0x4
.long .LCFI4-.LCFI3
.byte 0x84
.uleb128 0x3
.align 4
.LEFDE0:
.text
.Letext0:
.section .debug_loc,"",@progbits
.Ldebug_loc0:
.LLST0:
.long .LFB2-.Ltext0
.long .LCFI0-.Ltext0
.value 0x2
.byte 0x74
.sleb128 4
.long .LCFI0-.Ltext0
.long .LCFI1-.Ltext0
.value 0x1
.byte 0x51
.long .LCFI1-.Ltext0
.long .LCFI2-.Ltext0
.value 0x2
.byte 0x74
.sleb128 4
.long .LCFI2-.Ltext0
.long .LCFI3-.Ltext0
.value 0x2
.byte 0x74
.sleb128 8
.long .LCFI3-.Ltext0
.long .LFE2-.Ltext0
.value 0x2
.byte 0x75
.sleb128 8
.long 0x0
.long 0x0
.file 2 "/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/stddef.h"
.file 3 "/usr/include/bits/types.h"
.file 4 "/usr/include/stdio.h"
.file 5 "/usr/include/libio.h"
.section .debug_info
.long 0x334
.value 0x2
.long .Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.long .LASF51
.byte 0x1
.long .LASF52
.long .LASF53
.long .Ltext0
.long .Letext0
.long .Ldebug_line0
.uleb128 0x2
.long .LASF8
.byte 0x2
.byte 0xd6
.long 0x30
.uleb128 0x3
.byte 0x4
.byte 0x7
.long .LASF0
.uleb128 0x3
.byte 0x1
.byte 0x8
.long .LASF1
.uleb128 0x3
.byte 0x2
.byte 0x7
.long .LASF2
.uleb128 0x3
.byte 0x4
.byte 0x7
.long .LASF3
.uleb128 0x3
.byte 0x1
.byte 0x6
.long .LASF4
.uleb128 0x3
.byte 0x2
.byte 0x5
.long .LASF5
.uleb128 0x4
.byte 0x4
.byte 0x5
.string "int"
.uleb128 0x3
.byte 0x8
.byte 0x5
.long .LASF6
.uleb128 0x3
.byte 0x8
.byte 0x7
.long .LASF7
.uleb128 0x2
.long .LASF9
.byte 0x3
.byte 0x38
.long 0x61
.uleb128 0x2
.long .LASF10
.byte 0x3
.byte 0x8d
.long 0x85
.uleb128 0x3
.byte 0x4
.byte 0x5
.long .LASF11
.uleb128 0x2
.long .LASF12
.byte 0x3
.byte 0x8e
.long 0x6f
.uleb128 0x5
.byte 0x4
.byte 0x7
.uleb128 0x6
.byte 0x4
.uleb128 0x7
.byte 0x4
.long 0xa2
.uleb128 0x3
.byte 0x1
.byte 0x6
.long .LASF13
.uleb128 0x2
.long .LASF14
.byte 0x4
.byte 0x31
.long 0xb4
.uleb128 0x8
.long .LASF44
.byte 0x94
.byte 0x4
.byte 0x2d
.long 0x274
.uleb128 0x9
.long .LASF15
.byte 0x5
.value 0x110
.long 0x5a
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0x9
.long .LASF16
.byte 0x5
.value 0x115
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x4
.uleb128 0x9
.long .LASF17
.byte 0x5
.value 0x116
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x8
.uleb128 0x9
.long .LASF18
.byte 0x5
.value 0x117
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0xc
.uleb128 0x9
.long .LASF19
.byte 0x5
.value 0x118
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x10
.uleb128 0x9
.long .LASF20
.byte 0x5
.value 0x119
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x14
.uleb128 0x9
.long .LASF21
.byte 0x5
.value 0x11a
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x18
.uleb128 0x9
.long .LASF22
.byte 0x5
.value 0x11b
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x1c
.uleb128 0x9
.long .LASF23
.byte 0x5
.value 0x11c
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x20
.uleb128 0x9
.long .LASF24
.byte 0x5
.value 0x11e
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x24
.uleb128 0x9
.long .LASF25
.byte 0x5
.value 0x11f
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x28
.uleb128 0x9
.long .LASF26
.byte 0x5
.value 0x120
.long 0x9c
.byte 0x2
.byte 0x23
.uleb128 0x2c
.uleb128 0x9
.long .LASF27
.byte 0x5
.value 0x122
.long 0x2b2
.byte 0x2
.byte 0x23
.uleb128 0x30
.uleb128 0x9
.long .LASF28
.byte 0x5
.value 0x124
.long 0x2b8
.byte 0x2
.byte 0x23
.uleb128 0x34
.uleb128 0x9
.long .LASF29
.byte 0x5
.value 0x126
.long 0x5a
.byte 0x2
.byte 0x23
.uleb128 0x38
.uleb128 0x9
.long .LASF30
.byte 0x5
.value 0x12a
.long 0x5a
.byte 0x2
.byte 0x23
.uleb128 0x3c
.uleb128 0x9
.long .LASF31
.byte 0x5
.value 0x12c
.long 0x7a
.byte 0x2
.byte 0x23
.uleb128 0x40
.uleb128 0x9
.long .LASF32
.byte 0x5
.value 0x130
.long 0x3e
.byte 0x2
.byte 0x23
.uleb128 0x44
.uleb128 0x9
.long .LASF33
.byte 0x5
.value 0x131
.long 0x4c
.byte 0x2
.byte 0x23
.uleb128 0x46
.uleb128 0x9
.long .LASF34
.byte 0x5
.value 0x132
.long 0x2be
.byte 0x2
.byte 0x23
.uleb128 0x47
.uleb128 0x9
.long .LASF35
.byte 0x5
.value 0x136
.long 0x2ce
.byte 0x2
.byte 0x23
.uleb128 0x48
.uleb128 0x9
.long .LASF36
.byte 0x5
.value 0x13f
.long 0x8c
.byte 0x2
.byte 0x23
.uleb128 0x4c
.uleb128 0x9
.long .LASF37
.byte 0x5
.value 0x148
.long 0x9a
.byte 0x2
.byte 0x23
.uleb128 0x54
.uleb128 0x9
.long .LASF38
.byte 0x5
.value 0x149
.long 0x9a
.byte 0x2
.byte 0x23
.uleb128 0x58
.uleb128 0x9
.long .LASF39
.byte 0x5
.value 0x14a
.long 0x9a
.byte 0x2
.byte 0x23
.uleb128 0x5c
.uleb128 0x9
.long .LASF40
.byte 0x5
.value 0x14b
.long 0x9a
.byte 0x2
.byte 0x23
.uleb128 0x60
.uleb128 0x9
.long .LASF41
.byte 0x5
.value 0x14c
.long 0x25
.byte 0x2
.byte 0x23
.uleb128 0x64
.uleb128 0x9
.long .LASF42
.byte 0x5
.value 0x14e
.long 0x5a
.byte 0x2
.byte 0x23
.uleb128 0x68
.uleb128 0x9
.long .LASF43
.byte 0x5
.value 0x150
.long 0x2d4
.byte 0x2
.byte 0x23
.uleb128 0x6c
.byte 0x0
.uleb128 0xa
.long .LASF54
.byte 0x5
.byte 0xb4
.uleb128 0x8
.long .LASF45
.byte 0xc
.byte 0x5
.byte 0xba
.long 0x2b2
.uleb128 0xb
.long .LASF46
.byte 0x5
.byte 0xbb
.long 0x2b2
.byte 0x2
.byte 0x23
.uleb128 0x0
.uleb128 0xb
.long .LASF47
.byte 0x5
.byte 0xbc
.long 0x2b8
.byte 0x2
.byte 0x23
.uleb128 0x4
.uleb128 0xb
.long .LASF48
.byte 0x5
.byte 0xc0
.long 0x5a
.byte 0x2
.byte 0x23
.uleb128 0x8
.byte 0x0
.uleb128 0x7
.byte 0x4
.long 0x27b
.uleb128 0x7
.byte 0x4
.long 0xb4
.uleb128 0xc
.long 0xa2
.long 0x2ce
.uleb128 0xd
.long 0x97
.byte 0x0
.byte 0x0
.uleb128 0x7
.byte 0x4
.long 0x274
.uleb128 0xc
.long 0xa2
.long 0x2e4
.uleb128 0xd
.long 0x97
.byte 0x27
.byte 0x0
.uleb128 0x2
.long .LASF49
.byte 0x1
.byte 0x4
.long 0x2ef
.uleb128 0x7
.byte 0x4
.long 0xa9
.uleb128 0xe
.byte 0x1
.long .LASF55
.byte 0x1
.byte 0x6
.long 0x5a
.long .LFB2
.long .LFE2
.long .LLST0
.uleb128 0xf
.string "set"
.byte 0x1
.byte 0x7
.long 0x9c
.byte 0x2
.byte 0x91
.sleb128 -24
.uleb128 0x10
.long .LASF50
.byte 0x1
.byte 0x8
.long 0x5a
.byte 0x2
.byte 0x91
.sleb128 -20
.uleb128 0xf
.string "fl"
.byte 0x1
.byte 0x9
.long 0x2e4
.byte 0x2
.byte 0x91
.sleb128 -16
.byte 0x0
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.uleb128 0x5
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x6
.uleb128 0xf
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0x7
.uleb128 0xf
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x8
.uleb128 0x13
.byte 0x1
.uleb128 0x3
.uleb128 0xe
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x1
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x9
.uleb128 0xd
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0x5
.uleb128 0x49
.uleb128 0x13
.uleb128 0x38
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0xa
.uleb128 0x16
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0xb
.uleb128 0xd
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x38
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0xc
.uleb128 0x1
.byte 0x1
.uleb128 0x49
.uleb128 0x13
.uleb128 0x1
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0xd
.uleb128 0x21
.byte 0x0
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2f
.uleb128 0xb
.byte 0x0
.byte 0x0
.uleb128 0xe
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0xf
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x10
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.long 0x17
.value 0x2
.long .Ldebug_info0
.long 0x338
.long 0x2f5
.string "main"
.long 0x0
.section .debug_aranges,"",@progbits
.long 0x1c
.value 0x2
.long .Ldebug_info0
.byte 0x4
.byte 0x0
.value 0x0
.value 0x0
.long .Ltext0
.long .Letext0-.Ltext0
.long 0x0
.long 0x0
.section .debug_str,"MS",@progbits,1
.LASF12:
.string "__off64_t"
.LASF17:
.string "_IO_read_end"
.LASF8:
.string "size_t"
.LASF44:
.string "_IO_FILE"
.LASF19:
.string "_IO_write_base"
.LASF23:
.string "_IO_buf_end"
.LASF38:
.string "__pad2"
.LASF39:
.string "__pad3"
.LASF16:
.string "_IO_read_ptr"
.LASF52:
.string "test.c"
.LASF0:
.string "unsigned int"
.LASF36:
.string "_offset"
.LASF42:
.string "_mode"
.LASF28:
.string "_chain"
.LASF24:
.string "_IO_save_base"
.LASF1:
.string "unsigned char"
.LASF3:
.string "long unsigned int"
.LASF2:
.string "short unsigned int"
.LASF26:
.string "_IO_save_end"
.LASF54:
.string "_IO_lock_t"
.LASF27:
.string "_markers"
.LASF48:
.string "_pos"
.LASF55:
.string "main"
.LASF14:
.string "FILE"
.LASF30:
.string "_flags2"
.LASF47:
.string "_sbuf"
.LASF9:
.string "__quad_t"
.LASF31:
.string "_old_offset"
.LASF35:
.string "_lock"
.LASF45:
.string "_IO_marker"
.LASF50:
.string "surg"
.LASF32:
.string "_cur_column"
.LASF7:
.string "long long unsigned int"
.LASF29:
.string "_fileno"
.LASF22:
.string "_IO_buf_base"
.LASF53:
.string "/home/piotro/MathsCPP/test"
.LASF33:
.string "_vtable_offset"
.LASF10:
.string "__off_t"
.LASF43:
.string "_unused2"
.LASF6:
.string "long long int"
.LASF13:
.string "char"
.LASF51:
.string "GNU C 4.3.1 20080724 (prerelease)"
.LASF21:
.string "_IO_write_end"
.LASF5:
.string "short int"
.LASF25:
.string "_IO_backup_base"
.LASF15:
.string "_flags"
.LASF37:
.string "__pad1"
.LASF11:
.string "long int"
.LASF20:
.string "_IO_write_ptr"
.LASF40:
.string "__pad4"
.LASF41:
.string "__pad5"
.LASF46:
.string "_next"
.LASF4:
.string "signed char"
.LASF18:
.string "_IO_read_base"
.LASF49:
.string "filedesc"
.LASF34:
.string "_shortbuf"
.ident "GCC: (GNU) 4.3.1 20080724 (prerelease)"
.section .note.GNU-stack,"",@progbitsLibrary/package bug? If so, should I find another source for gcc with libc or just try to recompile it or something? I'm deep in the fog right now, any help or hint appreciated.
Still without hope of fixing this. I've read a bit about recompiling glibc, it seems its a pretty drudging task - and risky too. Is it actually possible that my arch is flawed somewhere? libc is vital, and I just can't get my head around why a function as simple as getc() does not work. Can anyone help ?
-------------------
Okay, I've dmesg'd my terminal after running the sample, and here's what I got:
a.out[3710]: segfault at 302e3036 ip b76120ad sp bf88adc0 error 4 in libc-2.8.so[b75ae000+13c000]I've checked out the error num in errno.h - > it seems something does interrupt my system call. Or the program's system call.
#define EINTR 4 /* Interrupted system call */So, maybe it's permissions after all ?
Help please, I'm desperate...
Indeed it does
BUT IT GETS BETTER !
I've installed diet libc. And the program works perfectly once compiled with
diet gcc test.c -o tester(gdb) run
Starting program: /home/piotro/MathsCPP/test/tester
SAMPLETEXTSAMPLETEXT
Program exited normally.But I'm curious why does the standard libc not work ?
And, if possible, how to replace the std libc w/ the diet one?
----------------------
Okay, I've accomplished it.
Once encountering the problem, just get yourself a nice little nifty piece of diet libc, then compile it on your very own machine, then "sudo nautilus", copy whats in /opt/diet/bin into /usr/bin, whats in /opt/diet/lib into /usr/lib and copy the whole /opt/diet/include into /usr.
Got it up and running. Any risk having the diet libc instead of a regular one ?
-----------------------
Hmm. I've learned about the risks quickly wink | its what happens when you 'presume' diet libc is compatbile with a gnu libc wink
Had to return to the regular glibc
The problem magically returned. Nowhere to turn to now, guess I'll have to look for an glibc equivalent....
-----------------------
It seems there is something wrong with libc-2.8.so. Sucks hard ! ! ! I just don't know how to downgrade now .
----------------------
I've installed libc-2.7.7 . we'll see where this takes me.
Seems it had taken me nowhere. Another failed attempt
----------------------
Another try, If that was the case then I am to be banished forever wink
Nope - my code was ok wink
----------------------
okay, downgraded - did not work (downloaded a 2.7.7 pkg and then just pasted it into my /), upgraded (via pacman) - at least the sample is now working. We'll see about the app I'm developing tommorow.
---------------------
the last instruction did help me. Its all working perfectly wink Cheers to those seeking a solution!
Topic may be closed if the mods were to wish so
Last edited by piotroxp (2008-08-04 20:43:00)
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
#2 2008-08-04 09:49:04
- drakosha
- Member
- Registered: 2006-01-03
- Posts: 253
- Website
Re: LIBC PROBLEM - SIGSEGV in getc()
You forgot to do fl = fopen("test.txt","r");
Offline
#3 2008-08-04 10:25:53
- piotroxp
- Member
- Registered: 2008-08-04
- Posts: 66
Re: LIBC PROBLEM - SIGSEGV in getc()
oooooh ;]
after the update above, I still recieve the segfault. added the fclose also. I've also shaped the code into a lil more readable form.
I'd try to take a shot at rebuilding my own libc 
any hints on how to accomplish this ?
Last edited by piotroxp (2008-08-04 10:37:13)
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
#4 2008-08-04 10:50:27
- JGC
- Developer
- Registered: 2003-12-03
- Posts: 1,664
Re: LIBC PROBLEM - SIGSEGV in getc()
Works fine here without problems.
Offline
#5 2008-08-04 10:56:18
- piotroxp
- Member
- Registered: 2008-08-04
- Posts: 66
Re: LIBC PROBLEM - SIGSEGV in getc()
You see that is the problem.
I recieve the segfaults - and I was trying to find the source of those. On my windows xp + msvs2005 it works flawlessly. And this is just a quick tester, not the app of course.
It seems it has got to be libc. Downgrading or updating?
-------------------
checking the linker options
-------------------
linker options didn't help
Still without hope of fixing this. I've read a bit about recompiling glibc, it seems its a pretty drudging task - and risky too. Is it actually possible that my arch is flawed somewhere? libc is vital, and I just can't get my head around why a function as simple as getc() does not work. Can anyone help ?
-------------------
Okay, I've dmesg'd my terminal after running the sample, and here's what I got:
a.out[3710]: segfault at 302e3036 ip b76120ad sp bf88adc0 error 4 in libc-2.8.so[b75ae000+13c000]I've checked out the error num in errno.h - > it seems something does interrupt my system call. Or the program's system call.
#define EINTR 4 /* Interrupted system call */So, maybe it's permissions after all ?
Last edited by piotroxp (2008-08-04 13:50:21)
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
#6 2008-08-04 17:28:26
- ghostHack
- Member
- From: Bristol UK
- Registered: 2008-02-29
- Posts: 261
Re: LIBC PROBLEM - SIGSEGV in getc()
have you tried just doing a re-install of glibc?
pacman -Sy glibcin case some file has got corrupted on your system.
Offline
#7 2008-08-04 17:51:18
- ornitorrincos
- Forum Fellow
- From: Bilbao, spain
- Registered: 2006-11-20
- Posts: 198
Re: LIBC PROBLEM - SIGSEGV in getc()
I have the same problem on arch64, you said to have an amd64, are you using the same arch?
-$: file /dev/zero
/dev/zero: symbolic link to '/dev/brain'
Offline
#8 2008-08-04 18:15:25
- piotroxp
- Member
- Registered: 2008-08-04
- Posts: 66
Re: LIBC PROBLEM - SIGSEGV in getc()
have you tried just doing a re-install of glibc?
Code:
pacman -Sy glibc
^^ done that, still not working. tried embedded libc - but it didn't compile, and I didn't want to waste time on finding deps
ornito,
no, I actually have i686 but I run it on an amd64 processor. With my previous installation of arch, everything was perfect. I also use the reiserfs as my filesystem (though I seriously doubt that causing the problem). I also doubt that its an amd64-based-problem.
No clue whatsoever. As curious as it may seem, the stl streams work prefectly. The standard c lib does not, and its pretty much bothersome...
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
#9 2008-08-04 18:35:19
- ornitorrincos
- Forum Fellow
- From: Bilbao, spain
- Registered: 2006-11-20
- Posts: 198
Re: LIBC PROBLEM - SIGSEGV in getc()
and does this still give you the segmentation fault?
#include "stdio.h"
#include "stdlib.h"
typedef FILE* filedesc;
int main()
{
int surg;
filedesc fl;
fl=fopen("test.txt","r");
if(fl == NULL)
{
printf("%s","arch rox!\n");
}
else
{
while((surg=getc(fl)) != EOF){
printf("%c",surg);
}
fclose(fl);
}
return 0;
}althought I think is the same with the exception of the braces and return
Last edited by ornitorrincos (2008-08-04 18:36:41)
-$: file /dev/zero
/dev/zero: symbolic link to '/dev/brain'
Offline
#10 2008-08-04 18:52:19
- piotroxp
- Member
- Registered: 2008-08-04
- Posts: 66
Re: LIBC PROBLEM - SIGSEGV in getc()
Indeed it does
BUT IT GETS BETTER !
I've installed diet libc. And the program works perfectly once compiled with
diet gcc test.c -o tester(gdb) run
Starting program: /home/piotro/MathsCPP/test/tester
SAMPLETEXTSAMPLETEXT
Program exited normally.But I'm curious why does the standard libc not work ?
And, if possible, how to replace the std libc w/ the diet one?
----------------------
Okay, I've accomplished it.
Once encountering the problem, just get yourself a nice little nifty piece of diet libc, then compile it on your very own machine, then "sudo nautilus", copy whats in /opt/diet/bin into /usr/bin, whats in /opt/diet/lib into /usr/lib and copy the whole /opt/diet/include into /usr.
Got it up and running. Any risk having the diet libc instead of a regular one ?
-----------------------
Hmm. I've learned about the risks quickly | its what happens when you 'presume' diet libc is compatbile with a gnu libc
Had to return to the regular glibc
The problem magically returned. Nowhere to turn to now, guess I'll have to look for an glibc equivalent....
-----------------------
It seems there is something wrong with libc-2.8.so. Sucks hard ! ! ! I just don't know how to downgrade now .
----------------------
I've installed libc-2.7.7 . we'll see where this takes me.
Seems it had taken me nowhere. Another failed attempt
----------------------
Another try, If that was the case then I am to be banished forever
Nope - my code was ok
----------------------
okay, downgraded - did not work (downloaded a 2.7.7 pkg and then just pasted it into my /), upgraded (via pacman) - at least the sample is now working. We'll see about the app I'm developing tommorow.
---------------------
the last instruction did help me. Its all working perfectly Cheers to those seeking a solution!
Topic may be closed if the mods were to wish so
Last edited by piotroxp (2008-08-04 20:36:44)
I invented EM Field Patterns and fixed Feynmann's Diagrams so they are physical.
Offline
Pages: 1