rawhide issues

[Anthony Green]

I see the following issues with rawhide (on x86) right now...

* I'm not getting any stack traces, just <<No stacktrace available>>


* Eclipse fails and the log contains the following errors (with no
stacktraces):

java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context:
org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION

java.lang.Exception: Cannot initialize Update Configurator

java.lang.IllegalStateException: Bundle
initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.


* aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1.  I can't
see where this comes from.


Any ideas?

AG

[Tom Tromey]

Anthony> * I'm not getting any stack traces, just <<No
Anthony> stacktrace available>>

This is

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175834

No diagnosis yet that I know of.


Anthony> * Eclipse fails and the log contains the following errors (with no
Anthony> stacktraces):
Anthony> java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context:
org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION

This is fixed in gcc svn; I thought this made it to an RPM.

See

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175833

Also GCC PR 25429


The rest I don't know about.

Tom

[Gary Benson]

Anthony Green wrote:
>  aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC
>  4.1.  I can't see where this comes from. 
It comes from rpm, via $RPM_OPT_FLAGS.

Cheers,
Gary

[Andrew Haley]

Anthony Green writes:
>  I see the following issues with rawhide (on x86) right now...
>  
>  * I'm not getting any stack traces, just <<No stacktrace available>>
>  
>  
>  * Eclipse fails and the log contains the following errors (with no
>  stacktraces):
>  
>  java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context:
> org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION
>  
>  java.lang.Exception: Cannot initialize Update Configurator
>  
>  java.lang.IllegalStateException: Bundle
> initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.
>  
>  
>  * aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1.  I can't
> see where this comes from.
>  
>  
>  Any ideas? 
gcc is emitting bad unwinder data for some routines.  This isn't a bug
in the gcc unwinder itself, because gdb has the same problems.  Look
at Frame 7 and Frame 9:

Breakpoint 7, _Unwind_Find_FDE (pc=0xb7fbdf76, bases=0xbffff0d0)
    at ../../gcc/unwind-dw2-fde-glibc.c:410
Current language:  auto; currently c
0xb7fbdf76 <_Unwind_Backtrace+30>:      decl   0xfffed485(%ebp)
(gdb) bt
#0  _Unwind_Find_FDE (pc=0xb7fbdf76, bases=0xbffff0d0)
    at ../../gcc/unwind-dw2-fde-glibc.c:410
#1  0xb7fbd0dc in uw_frame_state_for (context=0xbffff07c, fs=0xbfffeeb8)
    at ../../gcc/unwind-dw2.c:977
#2  0xb7fbdd50 in uw_init_context_1 (context=0xbffff07c,
    outer_cfa=0xbffff0f0, outer_ra=0xb73b8ed4)
    at ../../gcc/unwind-dw2.c:1254
#3  0xb7fbdf77 in _Unwind_Backtrace (
    trace=0xb73b8f34 <_Jv_StackTrace::UnwindTraceFn(_Unwind_Context*, void*)>,
trace_argument=0xbffff8f0) at ../../gcc/unwind.inc:287
#4  0xb73b8ed4 in _Jv_StackTrace::GetStackTrace ()
    at ../../../libjava/stacktrace.cc:160
#5  0xb73e74db in java::lang::VMThrowable::fillInStackTrace ()
    at ../../../libjava/java/lang/natVMThrowable.cc:33
#6  0xb75ca38b in java.lang.Throwable.fillInStackTrace() (
    this=0xb75ca47b)
    at ../../../libjava/classpath/java/lang/Throwable.java:498
#7  0x000fab10 in ?? ()
#8  0xb75ca47b in java.lang.Throwable.Throwable(java.lang.String) (
    this=0xb75ca860, message=0xfab10)
    at ../../../libjava/classpath/java/lang/Throwable.java:159
#9  0x080491a0 in _methods0 ()
#10 0xb75ca860 in java.lang.Throwable.Throwable() (this=0xfab10)
    at ../../../libjava/classpath/java/lang/Throwable.java:146
#11 0x08048a2c in Hello.main(java.lang.String[]) (args=0x27fa8)
    at Hello.java:13
#12 0xb73d8b17 in gnu::java::lang::MainThread::call_main (this=0x63e38)
    at ../../../libjava/gnu/java/lang/natMainThread.cc:47
#13 0xb7415823 in gnu.java.lang.MainThread.run() (this=0x63e38)
    at ../../../libjava/gnu/java/lang/MainThread.java:105
#14 0xb73e6e81 in _Jv_ThreadRun (thread=0x63e38)
    at ../../../libjava/java/lang/natThread.cc:299
#15 0xb73ad810 in _Jv_RunMain (vm_args=0x0, klass=0x8049240, name=0x0,
    argc=1, argv=0xbffffb24, is_jar=false)
    at ../../../libjava/prims.cc:1389
#16 0xb73ad97a in _Jv_RunMain (klass=0x8049240, name=0x0, argc=1,
    argv=0xbffffb24, is_jar=false) at ../../../libjava/prims.cc:1400
#17 0xb73ad9bb in JvRunMain (klass=0x8049240, argc=1, argv=0xbffffb24)
    at ../../../libjava/prims.cc:1406
#18 0x080489b9 in main (argc=Cannot access memory at address 0x0
) at /tmp/ccEsUlnr.i:11

[Andrew Haley]

Anthony, do you know exactly when this started to happen?

Andrew.

[Anthony Green]

On Mon, 2005-12-19 at 13:43 +0000, Andrew Haley wrote:
>  Anthony, do you know exactly when this started to happen? 
I believe the GCC 4.1 rawhide rpm has always had this problem.

AG

[Andrew Haley]

Andrew Haley writes:
>  Anthony Green writes:
>   > I see the following issues with rawhide (on x86) right now...
>   > 
>   > * I'm not getting any stack traces, just <<No stacktrace
> available>>
>   > 
>   > 
>   > * Eclipse fails and the log contains the following errors (with no
>   > stacktraces):
>   > 
>   > java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context:
> org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION
>   > 
>   > java.lang.Exception: Cannot initialize Update Configurator
>   > 
>   > java.lang.IllegalStateException: Bundle
> initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.
>   > 
>   > 
>   > * aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1.  I
> can't see where this comes from.
>   > 
>   > 
>   > Any ideas?
>  
>  gcc is emitting bad unwinder data for some routines.  This isn't a bug
>  in the gcc unwinder itself, because gdb has the same problems.  Look
>  at Frame 7 and Frame 9: 
BTW, I don't have this problem when building gcc from FSF sources.

Andrew.

[Andrew Haley]

Andrew Haley writes:
>  Andrew Haley writes:
>   > Anthony Green writes:
>   >  > I see the following issues with rawhide (on x86) right now...
>   >  > 
>   >  > * I'm not getting any stack traces, just <<No stacktrace
> available>>
>   >  > 
>   >  > 
>   >  > * Eclipse fails and the log contains the following errors (with no
>   >  > stacktraces):
>   >  > 
>   >  > java.lang.IllegalAccessError: org.xml.sax.helpers.NamespaceSupport$Context:
> org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION
>   >  > 
>   >  > java.lang.Exception: Cannot initialize Update Configurator
>   >  > 
>   >  > java.lang.IllegalStateException: Bundle
> initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.
>   >  > 
>   >  > 
>   >  > * aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC 4.1.  I
> can't see where this comes from.
>   >  > 
>   >  > 
>   >  > Any ideas?
>   > 
>   > gcc is emitting bad unwinder data for some routines.  This isn't a bug
>   > in the gcc unwinder itself, because gdb has the same problems.  Look
>   > at Frame 7 and Frame 9:
>  
>  BTW, I don't have this problem when building gcc from FSF sources. 
You'll have to make your window hugely wide to read this mail.

Here's the difference.  On the left, we have gcc version 4.1.0 20051212 (prerelease),

on the right we have gcc version 4.1.0 20051214 (Red Hat 4.1.0-0.9)

The one on the right is the one that works.

You'll note that the bad one uses three push instructions and then
sets CFA offset to 12.  This is wrong AFAICS: the original CFA offset
at function entry is 4, so if you push three registers, the CFA offset
should be 16.  The code on the right subtracts 12 from sp --
allocating three words -- and then sets CFA offset to 16.  This one is
correct, and we get a Java stacktrace.

Both built on the same box.  However, the 4.1 build was
i686-pc-linux-gnu, and the RPM build was i386-pc-linux-gnu.  I'm
guessing that is the *real* difference, and I'm investigating building
4.1 branch with host=i386-pc-linux-gnu.

Andrew.


00a328f8 <java.lang.Throwable.Throwable(java.lang.String)>:                         
                             00a50db0
<java.lang.Throwable.Throwable(java.lang.String)>:							    
  a328f8:       56                      push   %esi								    a50db0:       83 ec 0c     
          sub    $0xc,%esp							    
  a328f9:       53                      push   %ebx								    a50db3:       89 5c 24 04  
          mov    %ebx,0x4(%esp)							    
  a328fa:       50                      push   %eax								    a50db7:       e8 a9 41 dc
ff          call   814f65 <__i686.get_pc_thunk.bx>					    
  a328fb:       e8 00 00 00 00          call   a32900
<java.lang.Throwable.Throwable(java.lang.String)+0x8>	    a50dbc:       81 c3 fc 5d
6f 00       add    $0x6f5dfc,%ebx							    
  a32900:       5b                      pop    %ebx								    a50dc2:       89 74 24 08  
          mov    %esi,0x8(%esp)							    
  a32901:       81 c3 20 9b 65 00       add    $0x659b20,%ebx							    a50dc6:       8b
74 24 10             mov    0x10(%esp),%esi							    
  a32907:       8b 74 24 10             mov    0x10(%esp),%esi							    a50dca:       89
34 24                mov    %esi,(%esp)							    
  a3290b:       89 34 24                mov    %esi,(%esp)							    a50dcd:       e8 36
14 dc ff          call   812208 <java.lang.Object.Object()@plt>				    
  a3290e:       e8 8d ed dd ff          call   8116a0
<java.lang.Object.Object()@plt>				    a50dd2:       89 34 24                mov   
%esi,(%esp)							    
  a32913:       89 34 24                mov    %esi,(%esp)							    a50dd5:       e8 6e
a7 da ff          call   7fb548 <java.lang.Throwable.finit$()@plt>			    
  a32916:       e8 c5 82 dc ff          call   7fabe0
<java.lang.Throwable.finit$()@plt>			    a50dda:       8b 06                   mov  
 (%esi),%eax							    
  a3291b:       8b 06                   mov    (%esi),%eax							    a50ddc:       89 34
24                mov    %esi,(%esp)							    
  a3291d:       89 34 24                mov    %esi,(%esp)							    a50ddf:       ff 50
3c                call   *0x3c(%eax)							    
  a32920:       ff 50 3c                call   *0x3c(%eax)							    a50de2:       8b 44
24 14             mov    0x14(%esp),%eax							    
  a32923:       8b 44 24 14             mov    0x14(%esp),%eax							    a50de6:       89
46 04                mov    %eax,0x4(%esi)							    
  a32927:       89 46 04                mov    %eax,0x4(%esi)							    a50de9:       8b
5c 24 04             mov    0x4(%esp),%ebx							    
  a3292a:       5e                      pop    %esi								    a50ded:       8b 74 24 08  
          mov    0x8(%esp),%esi							    
  a3292b:       5b                      pop    %ebx								    a50df1:       83 c4 0c     
          add    $0xc,%esp							    
  a3292c:       5e                      pop    %esi								    a50df4:       c3           
          ret    									    
  a3292d:       c3                      ret    									
														
00058f08 0000001c 0003252c FDE cie=000269e0 pc=00a328f8..00a3292e						  														   

  Augmentation data:     00 00 00 00										  00053714 0000001c 0002f1f4 FDE
cie=00024524 pc=00a50d90..00a50db0						    
														    Augmentation data:     00 00 00 00										    
  DW_CFA_advance_loc: 1 to 00a328f9										  														    
  DW_CFA_def_cfa_offset: 8											    DW_CFA_advance_loc: 1 to 00a50d91										    
  DW_CFA_advance_loc: 1 to 00a328fa										    DW_CFA_def_cfa_offset: 8											    
  DW_CFA_def_cfa_offset: 12											    DW_CFA_offset: r3 at cfa-8											    
  DW_CFA_offset: r3 at cfa-12											    DW_CFA_advance_loc: 14 to 00a50d9f										  
 
  DW_CFA_offset: r6 at cfa-8											    DW_CFA_def_cfa_offset: 16											    
  DW_CFA_nop													    DW_CFA_nop													    
														    DW_CFA_nop													    
00058f08 0000001c 0003252c FDE cie=000269e0 pc=00a328f8..00a3292e						   
DW_CFA_nop													    
   LOC   CFA      r3   r6   ra   										  														    
00a328f8 r4+4     u    u    c-4  										  
00a328f9 r4+8     u    u    c-4  										  00053714 0000001c 0002f1f4 FDE cie=00024524
pc=00a50d90..00a50db0	   
00a328fa r4+12    c-12 c-8  c-4  										     LOC   CFA      r3   ra   						   
														  00a50d90 r4+4     u    c-4  						   
														  00a50d91 r4+8     c-8  c-4  						   
														  00a50d9f r4+16    c-8  c-4

[Andrew Haley]

Andrew Haley writes:
>  Andrew Haley writes:
>   > Andrew Haley writes:
>   >  > Anthony Green writes:
>   >  >  > I see the following issues with rawhide (on x86) right now...
>   >  >  > 
>   >  >  > * I'm not getting any stack traces, just <<No stacktrace
> available>>
>   >  >  > 
>   >  >  > 
>   >  >  > * Eclipse fails and the log contains the following errors (with no
>   >  >  > stacktraces):
>   >  >  > 
>   >  >  > java.lang.IllegalAccessError:
> org.xml.sax.helpers.NamespaceSupport$Context:
> org.xml.sax.helpers.NamespaceSupport.EMPTY_ENUMERATION
>   >  >  > 
>   >  >  > java.lang.Exception: Cannot initialize Update Configurator
>   >  >  > 
>   >  >  > java.lang.IllegalStateException: Bundle
> initial@reference:file:plugins/org.eclipse.core.runtime_3.1.1.jar/ [1] is not active.
>   >  >  > 
>   >  >  > 
>   >  >  > * aot-compile-rpm is using -mcpu=i686, but -mcpu is deprecated in GCC
> 4.1.  I can't see where this comes from.
>   >  >  > 
>   >  >  > 
>   >  >  > Any ideas?
>   >  > 
>   >  > gcc is emitting bad unwinder data for some routines.  This isn't a bug
>   >  > in the gcc unwinder itself, because gdb has the same problems.  Look
>   >  > at Frame 7 and Frame 9:
>   > 
>   > BTW, I don't have this problem when building gcc from FSF sources.
>  
>  You'll have to make your window hugely wide to read this mail.
>  
>  Here's the difference.  On the left, we have gcc version 4.1.0 20051212 (prerelease),
>
>  on the right we have gcc version 4.1.0 20051214 (Red Hat 4.1.0-0.9)
>  
>  The one on the right is the one that works.
>  
>  You'll note that the bad one uses three push instructions and then
>  sets CFA offset to 12.  This is wrong AFAICS: the original CFA offset
>  at function entry is 4, so if you push three registers, the CFA offset
>  should be 16.  The code on the right subtracts 12 from sp --
>  allocating three words -- and then sets CFA offset to 16.  This one is
>  correct, and we get a Java stacktrace.
>  
>  Both built on the same box.  However, the 4.1 build was
>  i686-pc-linux-gnu, and the RPM build was i386-pc-linux-gnu.  I'm
>  guessing that is the *real* difference, and I'm investigating building
>  4.1 branch with host=i386-pc-linux-gnu. 
And here is 4.1 branch built with i386-pc-linux-gnu.  And guess what!
It's just as bad as the Fedora RPM.  OK, so I'm now going to go
digging into the DWARF output routines to see if I can discover the
root cause of this insanity.

Andrew.


00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>:
  a326a8:       56                      push   %esi
  a326a9:       53                      push   %ebx
  a326aa:       50                      push   %eax
  a326ab:       e8 00 00 00 00          call   a326b0
<java.lang.Throwable.Throwable(java.lang.String)+0x8>
  a326b0:       5b                      pop    %ebx
  a326b1:       81 c3 34 ee 6a 00       add    $0x6aee34,%ebx
  a326b7:       8b 74 24 10             mov    0x10(%esp),%esi
  a326bb:       89 34 24                mov    %esi,(%esp)
  a326be:       e8 7d f6 dd ff          call   811d40
<java.lang.Object.Object()@plt>
  a326c3:       89 34 24                mov    %esi,(%esp)
  a326c6:       e8 a5 8a dc ff          call   7fb170
<java.lang.Throwable.finit$()@plt>
  a326cb:       8b 06                   mov    (%esi),%eax
  a326cd:       89 34 24                mov    %esi,(%esp)
  a326d0:       ff 50 3c                call   *0x3c(%eax)
  a326d3:       8b 44 24 14             mov    0x14(%esp),%eax
  a326d7:       89 46 04                mov    %eax,0x4(%esi)
  a326da:       5e                      pop    %esi
  a326db:       5b                      pop    %ebx
  a326dc:       5e                      pop    %esi
  a326dd:       c3                      ret    
  a326de:       89 f6                   mov    %esi,%esi

00058d50 0000001c 00032528 FDE cie=0002682c pc=00a326a8..00a326de
  Augmentation data:     00 00 00 00

  DW_CFA_advance_loc: 1 to 00a326a9
  DW_CFA_def_cfa_offset: 8
  DW_CFA_advance_loc: 1 to 00a326aa
  DW_CFA_def_cfa_offset: 12
  DW_CFA_offset: r3 at cfa-12
  DW_CFA_offset: r6 at cfa-8

00058d50 0000001c 00032528 FDE cie=0002682c pc=00a326a8..00a326de
   LOC   CFA      r3   r6   ra   
00a326a8 r4+4     u    u    c-4  
00a326a9 r4+8     u    u    c-4  
00a326aa r4+12    c-12 c-8  c-4

[Andrew Haley]

Looking further, I realize that my analysis is quite wrong.  The "push
%eax" is promptly followed by "pop %ebx", so a CFA offset of 12 is
correct.  D'oh!

This is what comes of doing my thinking in public...  Still, I have
discovered this problem is tune=i386 specific.  I'll continue looking.


00a326a8 <java.lang.Throwable.Throwable(java.lang.String)>:
  a326a8:       56                      push   %esi
  a326a9:       53                      push   %ebx
  a326aa:       50                      push   %eax
  a326ab:       e8 00 00 00 00          call   a326b0
<java.lang.Throwable.Throwable(java.lang.String)+0x8>
  a326b0:       5b                      pop    %ebx


Andrew.