Opened 9 years ago

Closed 8 years ago

#701 closed defect (fixed)

kernel crash in 64 bit trunk build under 64 bit linux while gc'ing after creating large vector

Reported by: lispwizard Owned by:
Priority: normal Milestone:
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:

Description

I just checked all active tickets and didn't see any report like this. I also updated to the trunk and rebuilt to make sure this bug still exists there.

(setq *print-array* nil)

(setq foo (make-array 1000000000))

(length foo)

(setq foo nil)

1

2

3

4

(gc)

(the extra expressions/values were to get rid of pointers to the vector in *, and *) results in a sigsegv!

Change History (3)

comment:1 Changed 9 years ago by lispwizard

This now gives an error when trying to allocate the array (as of 1.6-dev-r14046M-trunk).

comment:2 Changed 9 years ago by gb

Unless you have > ~8GB of free RAM+swap space, trying to allocate ~8GB of memory should indeed fail. (I don't know how much memory you have; on a machine with 8GB of RAM and another several GB of swap, your example worked correctly.)

I was originally going to blame this on Linux's tendency to deliberately overcommit memory (to allow applications to allocate more memory than available resources would allow, in the hope that those resources will become available before the memory's actually referenced. I found that trying to allocate more memory than I had died in mysterious ways (similar to what you reported) on a Solaris box, and Solaris doesn't overcommit. CCL was quite simply misinterpreting the error return from the allocation attempt, thought that the allocation was successful, and later crashed because that quite simply wasn't the case.

Overcommit can lead to similar behaviors, but if the error you're now seeing is something like "Memory allocation request failed", that means that the OS didn't have 8GB available and didn't even want to lie and say that it did.

comment:3 Changed 8 years ago by rme

  • Resolution set to fixed
  • Status changed from new to closed

Fixed by r13954.

Note: See TracTickets for help on using tickets.