| View previous topic :: View next topic |
| Author |
Message |
dsharp
n00b
Joined: 30 Jan 2003
Posts: 6
|
 Posted: Thu Jan 30, 2003 7:41 am Post subject: Exception handling broken in gcc 3.2.1-r7? |
 |
|
Running the gcc3.2.1-r7 ebuild, and exception handling seems to be broken.
The following test program exhibits the error on my system:
| Code: |
#include <string>
#include <iostream>
int main(int, char*[])
{
try
{
throw std::string("Hi");
}
catch (std::string& s)
{
std::cout << s << std::endl;
}
catch (...)
{
std::cout << "BAD" << std::endl;
}
return 0;
}
|
When I run this program, I get an abort, despite the fact that the catch(...) should catch everything.
If I recompile with icc it works as expected, so it appears to be related to gcc somehow. The wierd thing is, on my friend's Gentoo system with the same compiler, and same binutils, exception handling works. Diffing the ASM from the compiler on his machine and ASM from the compiler on mine show no differences.
I thought perhaps the Grsecurity patch was interfering, so I recompiled my kernel and turned it off. Unfortunately, the problem persists, and I have no idea what could be the problem.
Anyone here run into this problem before and solved it?
Thanks,
Dave[/code] |
|
| Back to top |
|
 |
Zadeh
Tux's lil' helper
Joined: 31 Oct 2002
Posts: 131
|
| Posted: Thu Jan 30, 2003 11:48 am Post subject: |
|
|
| Works fine here with both -r6 and -r7. Maybe there is something more specific you haven't mentioned that contributes to the bug...? |
|
| Back to top |
|
|
dsharp
n00b
Joined: 30 Jan 2003
Posts: 6
|
| Posted: Thu Jan 30, 2003 2:18 pm Post subject: |
|
|
Perhaps there is something else contributing, but I'm at a loss as to what it coulud be. If anyone has any ideas, I'm willing to listen.
Dave |
|
| Back to top |
|
|
Zadeh
Tux's lil' helper
Joined: 31 Oct 2002
Posts: 131
|
| Posted: Thu Jan 30, 2003 8:06 pm Post subject: |
|
|
| Could you post the error you get? Way you compile it and preprocessed source, assembly output could be useful too. Are you running Gentoo stable? |
|
| Back to top |
|
|
dsharp
n00b
Joined: 30 Jan 2003
Posts: 6
|
| Posted: Sun Feb 02, 2003 3:59 am Post subject: |
|
|
| Zadeh wrote: | | Could you post the error you get? Way you compile it and preprocessed source, assembly output could be useful too. Are you running Gentoo stable? |
I'm running Gentoo 1.2 that I've upgraded to use gcc 3.2.1.
As you can see from the program below the program should print "Hi" when run. It should *NOT* abort since the catch(...) block should catch any other exceptions that are thrown. The problem is that when this program is run, it aborts rather than printing "Hi". This tells me exception handling is broken.
If I compile the program unchanged with Intel's compiler, icc, the program runs as expected.
Dave
test.cc:
| Code: | #include <string>
#include <iostream>
int main(int, char*[])
{
try
{
throw std::string("Hi");
}
catch (std::string& s)
{
std::cout << s << std::endl;
}
catch (...)
{
std::cout << "BAD" << std::endl;
}
return 0;
}
|
test.s:
| Code: |
.file "test.cc"
.local _ZSt8__ioinit
.comm _ZSt8__ioinit,1,1
.globl _Unwind_Resume
.section .rodata
.LC0:
.string "Hi"
.LC1:
.string "BAD"
.text
.align 2
.globl main
.type main,@function
main:
.LFB1:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
pushl %esi
.LCFI2:
pushl %ebx
.LCFI3:
subl $64, %esp
.LCFI4:
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
leal -40(%ebp), %eax
movl %eax, (%esp)
call _ZNSaIcEC1Ev
leal -40(%ebp), %eax
movl %eax, 8(%esp)
movl $.LC0, 4(%esp)
leal -24(%ebp), %eax
movl %eax, (%esp)
.LEHB0:
call _ZNSsC1EPKcRKSaIcE
.LEHE0:
jmp .L3
.L27:
movl %eax, -48(%ebp)
movl %edx, -52(%ebp)
movl -48(%ebp), %ebx
movl -52(%ebp), %esi
leal -40(%ebp), %eax
movl %eax, (%esp)
call _ZNSaIcED1Ev
movl %ebx, -48(%ebp)
movl %esi, -52(%ebp)
jmp .L23
.L3:
leal -40(%ebp), %eax
movl %eax, (%esp)
call _ZNSaIcED1Ev
movl $4, (%esp)
call __cxa_allocate_exception
movl %eax, %ebx
leal -24(%ebp), %eax
movl %eax, 4(%esp)
movl %ebx, (%esp)
call _ZNSsC1ERKSs
movl $_ZNSsD1Ev, 8(%esp)
movl $_ZTISs, 4(%esp)
movl %ebx, (%esp)
.LEHB1:
call __cxa_throw
.LEHE1:
.L26:
movl %eax, -48(%ebp)
movl %edx, -52(%ebp)
movl -48(%ebp), %ebx
movl -52(%ebp), %esi
leal -24(%ebp), %eax
movl %eax, (%esp)
call _ZNSsD1Ev
movl %ebx, -48(%ebp)
movl %esi, -52(%ebp)
.L28:
.L23:
cmpl $2, -52(%ebp)
je .L13
jmp .L18
.L13:
movl -48(%ebp), %eax
movl %eax, (%esp)
call __cxa_begin_catch
movl %eax, -44(%ebp)
movl -44(%ebp), %eax
movl %eax, 4(%esp)
movl $_ZSt4cout, (%esp)
.LEHB2:
call _ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4_S5_T1_E
movl $_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, 4(%esp)
movl %eax, (%esp)
call _ZNSolsEPFRSoS_E
.LEHE2:
jmp .L15
.L25:
movl %eax, -48(%ebp)
movl -48(%ebp), %ebx
call __cxa_end_catch
movl %ebx, -48(%ebp)
movl -48(%ebp), %eax
movl %eax, (%esp)
.LEHB3:
call _Unwind_Resume
.L15:
call __cxa_end_catch
.LEHE3:
jmp .L12
.L18:
movl -48(%ebp), %eax
movl %eax, (%esp)
call __cxa_begin_catch
movl $.LC1, 4(%esp)
movl $_ZSt4cout, (%esp)
.LEHB4:
call _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
movl $_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_, 4(%esp)
movl %eax, (%esp)
call _ZNSolsEPFRSoS_E
.LEHE4:
jmp .L20
.L24:
movl %eax, -48(%ebp)
movl -48(%ebp), %ebx
call __cxa_end_catch
movl %ebx, -48(%ebp)
movl -48(%ebp), %eax
movl %eax, (%esp)
.LEHB5:
call _Unwind_Resume
.L20:
call __cxa_end_catch
.LEHE5:
.L12:
movl $0, %eax
leal -8(%ebp), %esp
popl %ebx
popl %esi
popl %ebp
ret
.LFE1:
.Lfe1:
.size main,.Lfe1-main
.section .gcc_except_table,"a",@progbits
.align 4
.LLSDA1:
.byte 0xff
.byte 0x0
.uleb128 .LLSDATT1-.LLSDATTD1
.LLSDATTD1:
.byte 0x1
.uleb128 .LLSDACSE1-.LLSDACSB1
.LLSDACSB1:
.uleb128 .LEHB0-.LFB1
.uleb128 .LEHE0-.LEHB0
.uleb128 .L27-.LFB1
.uleb128 0x5
.uleb128 .LEHB1-.LFB1
.uleb128 .LEHE1-.LEHB1
.uleb128 .L26-.LFB1
.uleb128 0x5
.uleb128 .LEHB2-.LFB1
.uleb128 .LEHE2-.LEHB2
.uleb128 .L25-.LFB1
.uleb128 0x0
.uleb128 .LEHB3-.LFB1
.uleb128 .LEHE3-.LEHB3
.uleb128 0x0
.uleb128 0x0
.uleb128 .LEHB4-.LFB1
.uleb128 .LEHE4-.LEHB4
.uleb128 .L24-.LFB1
.uleb128 0x0
.uleb128 .LEHB5-.LFB1
.uleb128 .LEHE5-.LEHB5
.uleb128 0x0
.uleb128 0x0
.LLSDACSE1:
.byte 0x1
.byte 0x0
.byte 0x2
.byte 0x7d
.byte 0x0
.byte 0x7d
.align 4
.long _ZTISs
.long 0
.LLSDATT1:
.text
.align 2
.type _Z41__static_initialization_and_destruction_0ii,@function
_Z41__static_initialization_and_destruction_0ii:
.LFB2:
pushl %ebp
.LCFI5:
movl %esp, %ebp
.LCFI6:
subl $24, %esp
.LCFI7:
cmpl $65535, 12(%ebp)
jne .L29
cmpl $1, 8(%ebp)
jne .L29
movl $_ZSt8__ioinit, (%esp)
call _ZNSt8ios_base4InitC1Ev
movl $__dso_handle, 8(%esp)
movl $0, 4(%esp)
movl $__tcf_0, (%esp)
call __cxa_atexit
.L29:
leave
ret
.LFE2:
.Lfe2:
.size _Z41__static_initialization_and_destruction_0ii,.Lfe2-_Z41__static_initialization_and_destruction_0ii
.align 2
.type __tcf_0,@function
__tcf_0:
.LFB3:
pushl %ebp
.LCFI8:
movl %esp, %ebp
.LCFI9:
subl $8, %esp
.LCFI10:
movl $_ZSt8__ioinit, (%esp)
call _ZNSt8ios_base4InitD1Ev
leave
ret
.LFE3:
.Lfe3:
.size __tcf_0,.Lfe3-__tcf_0
.weak _ZTISs
.section .gnu.linkonce.d._ZTISs,"aw",@progbits
.align 4
.type _ZTISs,@object
.size _ZTISs,8
_ZTISs:
.long _ZTVN10__cxxabiv117__class_type_infoE+8
.long _ZTSSs
.weak _ZTSSs
.section .gnu.linkonce.r._ZTSSs,"a",@progbits
.type _ZTSSs,@object
.size _ZTSSs,3
_ZTSSs:
.string "Ss"
.text
.align 2
.type _GLOBAL__I_main,@function
_GLOBAL__I_main:
.LFB4:
pushl %ebp
.LCFI11:
movl %esp, %ebp
.LCFI12:
subl $8, %esp
.LCFI13:
movl $65535, 4(%esp)
movl $1, (%esp)
call _Z41__static_initialization_and_destruction_0ii
leave
ret
.LFE4:
.Lfe4:
.size _GLOBAL__I_main,.Lfe4-_GLOBAL__I_main
.section .ctors,"aw",@progbits
.align 4
.long _GLOBAL__I_main
.weak pthread_mutex_unlock
.weak pthread_mutex_trylock
.weak pthread_mutex_lock
.weak pthread_create
.weak pthread_setspecific
.weak pthread_getspecific
.weak pthread_key_delete
.weak pthread_key_create
.weak pthread_once
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zPL"
.uleb128 0x1
.sleb128 -4
.byte 0x8
.uleb128 0x6
.byte 0x0
.long __gxx_personality_v0
.byte 0x0
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB1
.long .LFE1-.LFB1
.uleb128 0x4
.long .LLSDA1
.byte 0x4
.long .LCFI0-.LFB1
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.byte 0x4
.long .LCFI4-.LCFI1
.byte 0x83
.uleb128 0x4
.byte 0x86
.uleb128 0x3
.align 4
.LEFDE1:
.LSFDE3:
.long .LEFDE3-.LASFDE3
.LASFDE3:
.long .LASFDE3-.Lframe1
.long .LFB2
.long .LFE2-.LFB2
.uleb128 0x4
.long 0x0
.byte 0x4
.long .LCFI5-.LFB2
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI6-.LCFI5
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE3:
.LSFDE5:
.long .LEFDE5-.LASFDE5
.LASFDE5:
.long .LASFDE5-.Lframe1
.long .LFB3
.long .LFE3-.LFB3
.uleb128 0x4
.long 0x0
.byte 0x4
.long .LCFI8-.LFB3
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI9-.LCFI8
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE5:
.LSFDE7:
.long .LEFDE7-.LASFDE7
.LASFDE7:
.long .LASFDE7-.Lframe1
.long .LFB4
.long .LFE4-.LFB4
.uleb128 0x4
.long 0x0
.byte 0x4
.long .LCFI11-.LFB4
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI12-.LCFI11
.byte 0xd
.uleb128 0x5
.align 4
.LEFDE7:
.ident "GCC: (GNU) 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)"
|
The pre-processed source is over 700K I don't think posting it here would be a good idea.  |
|
| Back to top |
|
|
zhenlin
Veteran
Joined: 09 Nov 2002
Posts: 1361
|
| Posted: Sun Feb 02, 2003 7:33 am Post subject: |
|
|
| Perhaps the CFLAGS you used [to compile gcc] would be helpful. |
|
| Back to top |
|
|
Zadeh
Tux's lil' helper
Joined: 31 Oct 2002
Posts: 131
|
| Posted: Mon Feb 03, 2003 6:08 am Post subject: |
|
|
| I don't see anything wrong at a glance. Is the rest of your toolchain up to date? |
|
| Back to top |
|
|
dsharp
n00b
Joined: 30 Jan 2003
Posts: 6
|
| Posted: Tue Feb 04, 2003 6:43 pm Post subject: Solved! |
|
|
A friend of mine helped me figure it out.
Apparently there was an old version of libgcc_s.so in /lib
Removing it, and re-running ldconfig fixed everything. |
|
| Back to top |
|
|
Zadeh
Tux's lil' helper
Joined: 31 Oct 2002
Posts: 131
|
| Posted: Wed Feb 05, 2003 1:08 am Post subject: |
|
|
| Ah, that's got to be a difficult problem to track down. Sounds like a 1.2->1.4 artifact left behind. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
