Opened 13 years ago

Closed 12 years ago

#347 closed defect (duplicate)

as_area_destroy() broken on mips32 in GXemul

Reported by: Martin Decky Owned by: Martin Decky
Priority: major Milestone: 0.5.0
Component: helenos/kernel/mips32 Version: mainline
Keywords: malloc Cc:
Blocker for: Depends on:
See also:

Description

The implementation of as_area_destroy() seems to be broken on mips32 (in GXemul).

The malloc3 test fails (heap structure gets corrupted). The user space heap allocator has been extensively examined and tested on other platforms and it doesn't seem to be the culprit.

The problem can be completely worked around by changing the kernel function sys_as_area_destroy() into a no-op.

Change History (4)

comment:1 by Martin Decky, 13 years ago

I have tried several things with GXemul (both 0.4.7.2 and 0.6.0):

  • Invalidating all TLB entries instead of selective invalidation does not help.
  • GXemul has a rudimentary L1 and L2 cache implementation, but using the CACHE instruction does not help. I have not tried to trash the caches manually. I might try to disable the caches in GXemul entirely.
  • I have tried to setup all TLB entries as uncached, this did not help either.

I was unable to reproduce the bug in msim. I'm not particularly looking forward to a full-fledged debugging in GXemul ..

comment:2 by Martin Decky, 13 years ago

OK, even forcing GXemul to use zero-sized L1 and L2 cache does not help. This brings us back to the TLB itself. I am going to trace the TLB lookups in GXemul to tell what's happening.

comment:3 by Jakub Jermář, 12 years ago

Keywords: malloc added

comment:4 by Martin Decky, 12 years ago

Resolution: → duplicate
Status: new → closed

The bug is no longer reproducible, which suggests that the root cause was actually related to #395 and GXemul is innocent in this.

Note: See TracTickets for help on using tickets.