Unaligned access failures with apt-get on SMP K460.

parisc-linux Ryan Bradetich 3 participants 10 messages Jun 17, 2002

lore

Share & tools

lore

Ryan Bradetich

author

2002-06-17 00:22 UTC #0 lore raw

Hello parisc-linux hackers,

I (with a lot of help from Richard) am looking into a problem with apt-get .... on a SMP kernel for the K460.

The problem is that when I run apt-get <command> I get the following error message:

	apt-get(<PID>): unaligned access to 0x403ce094 at ip=0x4005e47f

This kernel has the DEBUG_UNALIGNED defined in arch/parisc/kernel/unaligned.c to provide additional debug information for unaligned accesses.

Here is the trace from the apt-get install sudo:

rebel:~# gdb /usr/bin/apt-get
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "hppa-linux"...(no debugging symbols
found)...
(gdb) break main
Breakpoint 1 at 0x24554
(gdb) run install sudo
Starting program: /usr/bin/apt-get install sudo
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Breakpoint 1, 0x00024554 in main ()
(gdb) continue
Continuing.
apt-get(165): unaligned access to 0x403ce094 at ip=0x4005e47f

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted

r00-03  00000000 00044a20 40098df3 403ce08c
r04-07  00000038 40111868 faf00c18 00049da4
r08-11  00049da0 faf00f18 faf01368 faf00e4c
r12-15  000129e7 faf00bf0 faf00a88 faf00bcc
r16-19  faf006c8 0000000a faf005b8 40111868
r20-23  000022c8 00000166 00000000 403ce044
r24-27  faf01368 00000038 000022c8 00040220
r28-31  0004a900 400c65a7 faf01500 000282a3
sr0-3   00000097 0000008f 00000000 00000097
sr4-7   00000097 00000097 00000097 00000097

IASQ: 00000097 00000097 IAOQ: 4005e47f 4005e483
IIR: 0c751290 ISR: 00000097 IOR: 403ce094
CPU: 2 CR30: ee294000 CR31: 11111111
ORIG_R28: 00000001
unaligned.c:183:emulate_store <7>store r21 (0x00000166) to 00000097:403ce094 for 4 bytes unaligned.c:365:handle_unaligned <7>ret = 0 apt-get (pid 165): Illegal instruction (code 8)

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000000000000000000000000 Not tainted

r00-03  00000000 ee58c000 40098df3 403ce08c
r04-07  00000038 40111868 faf00c18 00049da4
r08-11  10356810 10356810 faf01368 faf00e4c
r12-15  000129e7 faf00bf0 faf00a88 faf00bcc
r16-19  ee294380 0000000a faf005b8 40111868
r20-23  000022c8 00000166 00000000 403ce044
r24-27  ee81c03c eeb3db00 000022c8 00040220
r28-31  0004a900 400c65a7 faf01500 000282a3
sr0-3   00000097 0000008f 00000000 00000097
sr4-7   00000097 00000097 00000097 00000097

IASQ: 00000097 00000097 IAOQ: 4005e483 4005e487
IIR: 48340048 ISR: 00000000 IOR: ee58c024
CPU: 2 CR30: ee294000 CR31: 11111111
ORIG_R28: 00000001

Program received signal SIGILL, Illegal instruction. 0x4005e480 in DynamicMMap::Allocate(unsigned long) ()
from /usr/lib/libapt-pkg-libc6.2-3.so.3.2

(gdb)

Here is the instruction dump:

(gdb) x/10i 0x4005e470
0x4005e470 <_ZN11DynamicMMap8AllocateEm+100>: copy r4,r25
0x4005e474 <_ZN11DynamicMMap8AllocateEm+104>: ldo -1(r21),r21
0x4005e478 <_ZN11DynamicMMap8AllocateEm+108>: copy r20,r26
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
0x4005e480 <_ZN11DynamicMMap8AllocateEm+116>: b,l 0x4005d76c
<_init+232>,r31
0x4005e484 <_ZN11DynamicMMap8AllocateEm+120>: add,l r20,r4,r20
0x4005e488 <_ZN11DynamicMMap8AllocateEm+124>: stw r20,4(sr0,r3)
0x4005e48c <_ZN11DynamicMMap8AllocateEm+128>: copy ret1,ret0
0x4005e490 <_ZN11DynamicMMap8AllocateEm+132>: ldw -54(sr0,sp),rp
0x4005e494 <_ZN11DynamicMMap8AllocateEm+136>: ldw -3c(sr0,sp),r4
(gdb)

The instruction causing the unaligned trap is:
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)

As you can see from r3 (403ce08c) in the register dump is aligned on a 4-byte boundry. So the question is why is this trap being executed?

Also Richard thought the following two things looked wiered in the register dump:

	PSW is all 0's.
	r30 is faf01500 ... isn't userspace stack usually 0xbf??????

Note: The apt-get commands work fine on a UP kernel, and I am running against the unstable distribution. The same apt-get seems to work fine on the J200 with an SMP kernel too.

Any thoughts or insight is appreciated :)

Thanks,

- Ryan

John David Anglin

2002-06-17 01:00 UTC #1 lore raw

Quoted 5 lines

The instruction causing the unaligned trap is:
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
As you can see from r3 (403ce08c) in the register dump is aligned on a 4-byte boundry. So the question is why is this trap being executed?

Maybe the message is misleading. It looks as if the insn may be trying to write to readonly memory based of the value of r3.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

John David Anglin

2002-06-17 02:31 UTC #2 lore raw

Quoted 8 lines

Quoted 5 lines
The instruction causing the unaligned trap is:
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
As you can see from r3 (403ce08c) in the register dump is aligned on a 4-byte boundry. So the question is why is this trap being executed?
Maybe the message is misleading. It looks as if the insn may be trying to write to readonly memory based of the value of r3.

Sorry, this is wrong. Was _ZN11DynamicMMap8AllocateEm compiled with gcc-3.2? It looks as if C++ exceptions may be involved. This only has a chance of working with 3.2. I suspect that an exception handler is involved because r20 is not valid across calls and r20/r21 are used in C++ exceptions. The call looks to be a millicode call which might be part of the problem.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Ryan Bradetich

author

2002-06-17 03:04 UTC #3 lore raw

Dave,

This is the apt-get from debian unstable ... so if I had to guess I would assume that it is:

||/ Name Version Description
+++-==============-==============-============================================
ii gcc 3.0.4-6 The GNU C compiler.

any way I can tell from the binary?

thanks,

- Ryan

Quoted 21 lines · John David Anglin

Quoted 8 lines
Quoted 5 lines
The instruction causing the unaligned trap is:
0x4005e47c <_ZN11DynamicMMap8AllocateEm+112>: stw r21,8(sr0,r3)
As you can see from r3 (403ce08c) in the register dump is aligned on a 4-byte boundry. So the question is why is this trap being executed?
Maybe the message is misleading. It looks as if the insn may be trying to write to readonly memory based of the value of r3.
Sorry, this is wrong. Was _ZN11DynamicMMap8AllocateEm compiled with gcc-3.2? It looks as if C++ exceptions may be involved. This only has a chance of working with 3.2. I suspect that an exception handler is involved because r20 is not valid across calls and r20/r21 are used in C++ exceptions. The call looks to be a millicode call which might be part of the problem.
Dave
Signature · 2 lines
J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

John David Anglin

2002-06-17 04:12 UTC #4 lore raw

Re: [parisc-linux] Unaligned access failures with apt-get on SMP

Quoted 1 line

any way I can tell from the binary?

Not that I am aware of. On further thought, I think the user code is ok.

Studying you original message further, I see that the printout from unaligned.c is fully consistent with the register dump and user code. Thus, I have to think that the problem is actually in the kernel.

If the failure occurs all the time, I would put a break at 0x4005e47c and then set a large ignore count. Run the program and see how many times the break is hit before the fault occurs. Then, set the ignore count to 1 less than the number of hits and rerun. If the fault is deterministic, you should be able to determine the exact conditions which cause the "trap".

Oh, I remember that gdb may not print r3 correctly with info reg. It's better to use p $r3 or printf "0x%x\n", $r3.

Dave

Signature · 2 lines

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Ryan Bradetich

author

2002-06-17 20:44 UTC #5 lore raw

Re: [parisc-linux] Unaligned access failures with apt-get on SMP

John et all,

I recompiled the debian apt-get package this time leaving the debug symbols intact.

Here is the function that is causing the failure:

// DynamicMMap::Allocate - Pooled aligned allocation
/*{{{*/
// --------------------------------------------------------------------- /* This allocates an Item of size ItemSize so that it is aligned to its
size in the file. */
unsigned long DynamicMMap::Allocate(unsigned long ItemSize) {
// Look for a matching pool entry
Pool *I;
Pool *Empty = 0;
for (I = Pools; I != Pools + PoolCount; I++)

   {
      if (I->ItemSize == 0)
         Empty = I;
      if (I->ItemSize == ItemSize)
         break;

}

   // No pool is allocated, use an unallocated one
   if (I == Pools + PoolCount)
   {
      // Woops, we ran out, the calling code should allocate more.
      if (Empty == 0)
      {
         _error->Error("Ran out of allocation pools");
         return 0;
      }

      I = Empty;
      I->ItemSize = ItemSize;
      I->Count = 0;

}

   // Out of space, allocate some more
   if (I->Count == 0)
   {
      I->Count = 20*1024/ItemSize;
      I->Start = RawAllocate(I->Count*ItemSize,ItemSize);
   }

I->Count--;
unsigned long Result = I->Start;
I->Start += ItemSize;
return Result/ItemSize;
}

Here is my gdb output while tracing the failure:

root@rebel:~# gdb /usr/bin/apt-get 
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "hppa-linux"...

(gdb) b main
Breakpoint 1 at 0x27ea4: file apt-get.cc, line 2134.

(gdb) run install less
Starting program: /usr/bin/apt-get install less

Breakpoint 1, main (argc=3, argv=0x46e66) at apt-get.cc:2134
2134 CommandLine CmdL(Args,_config);

(gdb) b DynamicMMap::Allocate
Breakpoint 2 at 0x40050358: file contrib/mmap.cc, line 229.

(gdb) continue
Continuing.
Reading Package Lists... 0%
Breakpoint 2, DynamicMMap::Allocate(unsigned long) (this=0x4c900, ItemSize=275112) at contrib/mmap.cc:229
229 Pool *Empty = 0;

(gdb) bt
#0 DynamicMMap::Allocate(unsigned long) (this=0x4c900, ItemSize=275112) at contrib/mmap.cc:229
#1 0x400ba64c in pkgCacheGenerator::SelectFile(std::string, std::string, pkgIndexFile const&, unsigned long) (this=0xbff01020, File=

        {static npos = 4294967295, _M_dataplus = {<allocator<char>> =

{<No data fields>}, _M_p = 0x489f4 "/var/lib/dpkg/status"}, static _S_empty_rep_storage = {0, 0, 1, 18, 1, 0}}, Site={static npos = 4294967295, _M_dataplus = {<allocator<char>> = {<No data fields>}, _M_p = 0x432b4 ""}, static _S_empty_rep_storage = {0, 0, 1, 18, 1, 0}}, Index=@0x4bda0,

    Flags=1) at pkgcachegen.cc:404

#2 0x400e5a14 in debStatusIndex::Merge(pkgCacheGenerator&, OpProgress&) const (this=0x4bda0, Gen=@0xbff01020, Prog=@0xbff00d90) at /usr/include/g++-v3/bits/basic_string.h:863
#3 0x400bbf8c in BuildCache(pkgCacheGenerator&, OpProgress&, unsigned long&, unsigned long, std::__normal_iterator<pkgIndexFile**, std::vector<pkgIndexFile*, std::allocator<pkgIndexFile*> > >, std::__normal_iterator<pkgIndexFile**, std::vector<pkgIndexFile*, std::allocator<pkgIndexFile*> > >) (Gen=@0xbff01020, Progress=@0xbff00d90, CurrentSize=@0xbff01190,

    TotalSize=107592,

Start={<iterator<std::random_access_iterator_tag,pkgIndexFile*,int,pkgIndexFile**,pkgIndexFile*&>> = {<No data fields>}, _M_current = 0x4c578}, End=

{<iterator<std::random_access_iterator_tag,pkgIndexFile*,int,pkgIndexFile**,pkgIndexFile*&>> = {<No data fields>}, _M_current = 0x4c57c})

    at /usr/include/g++-v3/bits/stl_iterator.h:478
#4  0x400bd280 in pkgMakeStatusCache(pkgSourceList&, OpProgress&,
MMap**, bool) (List=@0xbff01020, Progress=@0xbff00d90,
OutMap=0xbff00990, AllowMem=224)
    at /usr/include/g++-v3/bits/stl_vector.h:187

#5 0x400ad8d4 in pkgCacheFile::Open(OpProgress&, bool) (this=0xbff00990, Progress=@0xbff00d90, WithLock=true) at cachefile.cc:70
#6 0x0002b794 in CacheFile::Open(bool) (this=0xbff00990, WithLock=56) at apt-get.cc:85

(gdb) n
DynamicMMap::Allocate(unsigned long) (this=0x4c900, ItemSize=275112) at contrib/mmap.cc:226
226 {

(gdb) n
DynamicMMap::Allocate(unsigned long) (this=0x4c900, ItemSize=56) at contrib/mmap.cc:230
230 for (I = Pools; I != Pools + PoolCount; I++)

(gdb) n
232 if (I->ItemSize == 0)