[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binary incompatibility among mipsel buildds

On 08/08/2010 08:42 PM, Camm Maguire wrote:

Greetings!  Forwarded from a conversation between Andreas and me.
Suggestions most welcome.

Take care,

=============================================================================
Hi,

I need to admit: ugh. I'm by far not an porter enough for this, but
please send your results to d-mips@l.d.o. I'm happy to provide
hardware data (mayer and rem are swarm machines, phrixos is loongson
2f), and let other people access the machines here if helpful. I
probably could also arrange access to an swarm-class mipsel machine.



Andi



* Camm Maguire (camm@maguirefamily.org) [100730 17:55]:

Greetings!

Regarding

  https://buildd.debian.org/fetch.cgi?pkg=axiom&arch=mipsel&ver=20100701-1&stamp=1280388149&file=log&as=raw

The gcl was built on phrixos, and I just successfully compiled axiom
the package there using this same gcl binary package.  There seems to
be some skew between the mipsel machines, and I think it involves
sigaction.

You still have the bad -60 binary built on some other mipsel machine
installed on phrixos.  This segfaults on startup, in the following
routine:

void
memory_protect(int on) {

   unsigned long i,beg,end= ((unsigned long)(((unsigned long)(((char *)(core_end))-0x0)>>14)));
   int writable=1;
   extern void install_segmentation_catcher(void);

   if (first_protectable_page==0) {
     for (i=page_multiple; i<  maxpage ; i++)
       if (type_map[i]!=t_other)
  break;
       else {


  sgc_type_map[i] = 4;
       }
     first_protectable_page= ((i) - (i % page_multiple));
   }
   if(page_multiple>  1)
     fix_for_page_multiple(first_protectable_page,end);

   if (on==0) {sgc_mprotect((first_protectable_page),
       (end - first_protectable_page), (4 | 1));
   install_segmentation_catcher();
Impossible to say without knowing what install_segmentation_catcher(), and presumably the SIGSEGV handler as well, are doing.
It could be many things. Single stepping through the code after the SIGSEGV with a recent gdb should shed some light on what is happening. 

David Daney



   return;
   }





   do {static struct sigaction action; action.__sigaction_handler.sa_handler = (void *)memprotect_handler; action.sa_flags = 0x10000000|0x00000008; sigemptyset(&action.sa_mask); sigaddset(&action.sa_mask,2); sigaddset(&action.sa_mask,14); sigaction(11,&action,0); sigaction(10,&action,0);} while (0);
   beg=first_protectable_page;
   writable = (((unsigned long)beg<(128*1024*(4>>2)/(1<<(14 -12))))&&  (sgc_type_map[beg]&  (4 | 1)));
   for (i=beg ; ++i<= end; ) {
     int wri = (((unsigned long)i<(128*1024*(4>>2)/(1<<(14 -12))))&&  (sgc_type_map[i]&  (4 | 1)));
     if ((wri==0&&  writable)
  || (writable ==0&&  wri)
  || i == end) {

       if (writable)
  make_writable(beg,i);
       else
  sgc_mprotect(beg,i-beg,writable);
       writable = wri;
       beg = i;
     }
   }
}


with the following strace:

lstat64("/usr/lib/gcl-2.6.7/unixport/saved_gcl", {st_mode=S_IFREG|0755, st_size=9231344, ...}) = 0
personality(0xffffffff /* PER_??? */)   = 0
rt_sigaction(SIGSEGV, {0x18000008, [RT_68 RT_71 RT_75 RT_80 RT_81 RT_85 RT_86 RT_87 RT_88 RT_90 RT_92 RT_94], SA_SIGINFO|0x422fe4}, NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {0x18000008, [RT_69 RT_72 RT_75 RT_76 RT_82 RT_84 RT_85 RT_86 RT_88 RT_89 RT_90 RT_91 RT_92 RT_93 RT_94], SA_SIGINFO|0x422fe4}, NULL, 16) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

The working -62 binary, built on and installed in my home on phrixos,
has the following strace:

personality(0xffffffff /* PER_??? */)   = 0
rt_sigaction(SIGSEGV, {0x18000008, [RT_68 RT_71 RT_75 RT_80 RT_81 RT_85 RT_86 RT_87 RT_88 RT_90 RT_92 RT_94], SA_SIGINFO|0x422fe4}, NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
mprotect(0xab8000, 1949696, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
rt_sigaction(SIGSEGV, {0x18000008, [RT_67 RT_68 RT_70 RT_71 RT_72 RT_74 RT_76 RT_77 RT_78 RT_80 RT_83 RT_84 RT_86 RT_87], SA_SIGINFO|0x422fe4}, NULL, 16) = 0
getrlimit(RLIMIT_DATA, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
sigaltstatck({ss_sp=0x6cbe98, ss_flags=0, ss_size=2097152}, NULL) = 0

The only thing I can spot is the RT_ flag difference in the second
sigaction call.  But both these faults occur inside of sigaction (it
appears), so my working guess is that the c libraries are binary
incompatible across some of the the mipsel buildds.

I would need access to two different machines to be able to compile
with debugging on for further info.  But I hope the above is enough.

Take care,

Andreas Barth<aba@not.so.argh.org>  writes:


* Camm Maguire (camm@maguirefamily.org) [100719 18:20]:

Greetings!  Is is possible the sigaction semantics have changed on
mipsel recently, and that rem might be running in an older
compatibility mode?

I've rebuilt gcl from the same -60 source on phrixous, and all appears
flawless.  The older binary appears to be faulting on starup around an
attempted sigaction trap of SIGSEGV and SIGBUS (no debugging symbols).
Any way I can replace the -60 mipsel deb in the archive without
forcing a rebuild everywhere else?


You can upload an +b1-package built by hand. Alternativly, if it can
build automatically, I can schedule an binNMU.


Andi






--
Camm Maguire			     		    camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



=============================================================================
Reply to: