Opened 9 years ago

Closed 9 years ago

#4963 closed bug (duplicate)

PANIC: heap: kernel heap has run out of memory

Reported by: mvfranz Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: #5816 Blocking:
Has a Patch: no Platform: All

Description

I am using svn revision 34025 and getting the PANIC: heap: kernel heap has run out of memory.

I am doing a build of gcc 4.3.3 that has the GCJ code added to it. This is running on a VMWare image and the kernel debugger BT does not seem to printout anything useful.

I have had this happen twice.

Change History (3)

comment:1 Changed 9 years ago by mvfranz

Had this happen again (probably the third time). I was looking for a file using find. I am using hrev35775.

PANIC: heap: kernel heap has run out of memory

Welcome to Kernel Debugging Land...
Thread 484463 "find" running on CPU 2
kdebug> bt
stack trace for thread 484463 "find"
    kernel stack: 0x812f3000 to 0x812f7000
      user stack: 0x7efef000 to 0x7ffef000
frame               caller     <image>:function + offset
 0 812f68b8 (+  32) 8006ec29   <kernel_x86> invoke_command_trampoline(void*: [34m0x812f6938[0m) + 0x0015
 1 812f68d8 (+  12) 800e20b8   <kernel_x86>:arch_debug_call_with_fault_handler + 0x001b
 2 812f68e4 (+  48) 8006cad6   <kernel_x86>:debug_call_with_fault_handler + 0x0051
 3 812f6914 (+  64) 8006efa6   <kernel_x86>:invoke_debugger_command + 0x00bb
 4 812f6954 (+  48) 8006f0c3   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: [34m0x801355a2[0m, int32: [34m0[0m, char*: NULL) + 0x0083
 5 812f6984 (+  32) 8006f18b   <kernel_x86>:invoke_debugger_command_pipe + 0x008b
 6 812f69a4 (+ 128) 80072f16   <kernel_x86> ExpressionParser<[32m0x812f6a74[0m>::_ParseCommandPipe(int&: [34m0x812f6a70[0m) + 0x0aae
 7 812f6a24 (+  48) 800756df   <kernel_x86> ExpressionParser<[32m0x812f6a74[0m>::EvaluateCommand(char const*: [34m0x801355a0[0m [36m"bt"[0m, int&: [34m0x812f6a70[0m) + 0x06df
 8 812f6a54 (+ 192) 80075858   <kernel_x86>:evaluate_debug_command + 0x0084
 9 812f6b14 (+  64) 8006d7a2   <kernel_x86> kernel_debugger_loop(char const*: [34m0x2[0m [31m"<???>"[0m, char const*: [34m0x8012a412[0m [36m"PANIC: "[0m, char*: [34m0x812f6b84[0m, int32: [34m-2147034808[0m) + 0x026c
10 812f6b54 (+  48) 8006d966   <kernel_x86> kernel_debugger_internal(char const*: [34m0x2[0m [31m"<???>"[0m, char const*: [34m0x0[0m [31m"<NULL>"[0m, char*: [34m0x812f6ba4[0m, int32: [34m-2147034314[0m) + 0x011c
11 812f6b84 (+  32) 8006db49   <kernel_x86>:panic + 0x0023
12 812f6ba4 (+  80) 80049296   <kernel_x86>:memalign + 0x02bd
13 812f6bf4 (+  32) 800492ee   <kernel_x86>:malloc + 0x0010
14 812f6c14 (+  64) 800a7578   <kernel_x86> create_new_vnode_and_lock(int32: [34m-2127598436[0m, int64: [34m-9137965596394165085[0m, vnode*&: [34m0x800a8b47[0m, bool&: [34m0x7c018f[0m) + 0x0018
15 812f6c54 (+  96) 800a8ccc   <kernel_x86> get_vnode(int32: [34m-2127598364[0m, int64: [34m4294967297[0m, vnode**: NULL, [34mtrue[0m, int32: [34m0[0m) + 0x01d6
16 812f6cb4 (+  64) 800aa821   <kernel_x86>:get_vnode + 0x002d
17 812f6cf4 (+  96) 814151e3   <bfs> bfs_lookup(fs_volume*: [34m0x829f71b8[0m, fs_vnode*: [34m0xceafffac[0m, char const*: [34m0xceb25420[0m [36m"DynamicAccessPermission.java"[0m, long long*: [34m0x812f6d7c[0m) + 0x0197
18 812f6d54 (+  64) 800a8fd8   <kernel_x86> lookup_dir_entry(vnode*: [34m0xceb0c1d8[0m, char const*: [34m0x1[0m [31m"<???>"[0m, vnode**: [34m0x1[0m) + 0x0062
19 812f6d94 (+  64) 800abb37   <kernel_x86> vnode_path_to_vnode(vnode*: NULL, char*: [34m0xce6d16a4[0m, [34mtrue[0m, int32: [34m0[0m, io_context*: [34m0xceb25420[0m, vnode**: [34m0xce6d16ac[0m, long long*: [34m0x812f6e14[0m) + 0x0130
20 812f6dd4 (+  48) 800ac572   <kernel_x86> vnode_path_to_vnode(vnode*: NULL, char*: NULL, [34mtrue[0m, int32: [34m0[0m, [34mtrue[0m, vnode**: NULL, long long*: [34m0x812f6e44[0m) + 0x004b
21 812f6e04 (+  64) 800ac654   <kernel_x86> path_to_vnode(char*: NULL, [34mfalse[0m, vnode**: NULL, long long*: NULL, [34mtrue[0m) + 0x00da
22 812f6e44 (+  48) 800adb67   <kernel_x86> fd_and_path_to_vnode(int32: [34m-2127597928[0m, char*: NULL, [34mfalse[0m, vnode**: [34m0xcf8afafc[0m, long long*: NULL, [34mtrue[0m) + 0x006e
23 812f6e74 (+  48) 800ae960   <kernel_x86> common_path_read_stat(int32: [34m-2127597872[0m, char*: NULL, [34mfalse[0m, stat*: [34m0xceb065a0[0m, [34mfalse[0m) + 0x0025
24 812f6ea4 (+ 160) 800aea81   <kernel_x86>:_user_read_stat + 0x00a8
25 812f6f44 (+ 100) 800e2692   <kernel_x86>:handle_syscall + 0x00af
user iframe at 0x812f6fa8 (end = 0x812f7000)
 eax 0x8a           ebx 0x2ec8a8        ecx 0x7ffed9ac   edx 0xffff0114
 esi 0x7ffedb04     edi 0x18038fd0      ebp 0x7ffed9d8   esp 0x812f6fdc
 eip 0xffff0114  eflags 0x212      user esp 0x7ffed9ac
 vector: 0x63, error code: 0x0
26 812f6fa8 (+   0) ffff0114   <commpage>:commpage_syscall + 0x0004
27 7ffed9d8 (+  32) 00206025   </boot/system/bin/find@0x00200000>:unknown + 0x6025
28 7ffed9f8 (+  32) 00204ccb   </boot/system/bin/find@0x00200000>:unknown + 0x4ccb
29 7ffeda18 (+  48) 00204df5   </boot/system/bin/find@0x00200000>:unknown + 0x4df5
30 7ffeda48 (+ 288) 00206185   </boot/system/bin/find@0x00200000>:unknown + 0x6185
31 7ffedb68 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
32 7ffedc88 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
33 7ffedda8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
34 7ffedec8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
35 7ffedfe8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
36 7ffee108 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
37 7ffee228 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
38 7ffee348 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
39 7ffee468 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
40 7ffee588 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
41 7ffee6a8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
42 7ffee7c8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
43 7ffee8e8 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
44 7ffeea08 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
45 7ffeeb28 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
46 7ffeec48 (+ 288) 0020683c   </boot/system/bin/find@0x00200000>:unknown + 0x683c
47 7ffeed68 (+  32) 00206a29   </boot/system/bin/find@0x00200000>:unknown + 0x6a29
48 7ffeed88 (+ 176) 00205722   </boot/system/bin/find@0x00200000>:unknown + 0x5722
49 7ffeee38 (+  32) 00205772   </boot/system/bin/find@0x00200000>:unknown + 0x5772
50 7ffeee58 (+ 272) 00205f2c   </boot/system/bin/find@0x00200000>:unknown + 0x5f2c
51 7ffeef68 (+  52) 00204a9d   </boot/system/bin/find@0x00200000>:unknown + 0x4a9d
52 7ffeef9c (+  64) 00105367   </boot/system/runtime_loader@0x00100000>:unknown + 0x5367
53 7ffeefdc (+   0) 7ffeefec   11319340:find_main_stack@0x7efef000 + 0xffffec

comment:2 Changed 9 years ago by bonefish

I case you can still reproduce it, the amount of RAM and swap of the system would be interesting, as well as the output of the KDL commands avail, page_stats, and swap.

comment:3 Changed 9 years ago by bonefish

Blocked By: 5816 added
Resolution: duplicate
Status: newclosed

Duplicate of #5816, which has more info attached.

Note: See TracTickets for help on using tickets.