bdsh dies on mips32

[Jakub Jermář]

bdsh (newer than 6001) will crash after successfully completing a command on mips32. The corresponding message in klog shows bogus Task ID and message ending with:

exception at 0x80edbf94: Unhandled exception Address Error - store.

I tried to track this to a particular change, and found that the last revision where this is not reproducible is 4597 and the first where I can reproduce this is 4601. In other words, the changes related to adding the new uspace memory allocator made this bug hittable on mips32. I also saw a similar misbehavior on arm32, where bdsh did not crash, but got hung instead.

I am adding keywords both for bdsh and malloc, and putting this under the uspace/libc category as it can be pretty much anything from these two or also something else.

[Jakub Jermář]

Replying to jermar:

bdsh (newer than 6001) will crash after successfully completing a command on mips32.

We are not that far yet, the revision should have been 4601

[Jakub Jermář]

Replying to jermar:

The corresponding message in klog shows bogus Task ID and message ending with:

exception at 0x80edbf94: Unhandled exception Address Error - store.

The bogus message was another bug caused by an incorrect stack alignment and was fixed in revision 4627. Now the message makes much more sense:

Task bdsh (18) killed due to an exception at 0x122b0: Unhandled exception Addres Error - store.

The bdsh address 0x122b0 points to realloc():

   1228c:       14400042        bnez    v0,12398 <realloc+0x2f8>
   12290:       a6000004        sh      zero,4(s0)
   12294:       0264102b        sltu    v0,s3,a0
   12298:       5040ffc2        beqzl   v0,121a4 <realloc+0x104>
   1229c:       2610000c        addiu   s0,s0,12
   122a0:       02151821        addu    v1,s0,s5
   122a4:       00952023        subu    a0,a0,s5
   122a8:       00642821        addu    a1,v1,a0
   122ac:       24020001        li      v0,1
   122b0:       ac640000        sw      a0,0(v1)
   122b4:       ac660008        sw      a2,8(v1)
   122b8:       a4620004        sh      v0,4(v1)
   122bc:       aca4fff8        sw      a0,-8(a1)
   122c0:       aca7fffc        sw      a3,-4(a1)
   122c4:       a6000004        sh      zero,4(s0)
   122c8:       ae060008        sw      a2,8(s0)
   122cc:       2610000c        addiu   s0,s0,12
   122d0:       ae95fff4        sw      s5,-12(s4)
   122d4:       ac67fffc        sw      a3,-4(v1)
   122d8:       1000ffb2        b       121a4 <realloc+0x104>
   122dc:       ac75fff8        sw      s5,-8(v1)

[Jakub Jermář]

Ok, now I am almost certain that this is a userspace allocator bug. I tracked the issue into bdsh's cli_set_prompt() and based on that I found a reproducible testcase:

        char *a, *b;

        b = malloc(255);
        a = malloc(17);
        a = realloc(a, 255);

You can try to place this code into init's main or just at the beginning of bdsh's cli_set_prompt. On mips32, you should get a fault.

[Jakub Jermář]

Replying to jermar:

         char *a
 
         a = malloc(17);
         a = realloc(a, 255);

This should actually be just enough to reproduce the bug.

[Jiri Svoboda]

The problem was in two places in realloc(). One: real_size was not a multiple of BASE_ALIGN, two: split_mark() was called with size as parameter, which again was not multiple of BASE_ALIGN. Fixed in r4642.