[RAMFS] crashes after running multiple instances of GIMP

[diver]

hrev57619 x86_64 running in VMware with 1GB.

Running 2 instances of GIMP crashes kernel. Possibly RAM size could be important.

[waddlesplash]

Looks like a NULL dereference, yes.

[waddlesplash]

I don't see any obvious missing NULL checks in that function or the ones it inlines. I guess the next thing is to determine what structure we are dealing with at offset 0x1a8.

[diver]

Now can be crashed with only one instance of GIMP with 1GB.

[waddlesplash]

Fixed in hrev57898.

[diver]

With hrev57898

KERN: low resource pages: note -> normal
KERN: low resource pages: normal -> note
KERN: low resource pages: note -> normal
KERN: low resource pages: normal -> note
KERN: low resource pages: note -> normal
KERN: low resource pages: normal -> note
KERN: PANIC: ASSERT FAILED (../haiku-git/src/add-ons/kernel/file_systems/ramfs/Node.cpp:69): fRefCount == 0
KERN: Welcome to Kernel Debugging Land...
KERN: Thread 2174 "script-fu" running on CPU 0
KERN: stack trace for thread 2174 "script-fu"
KERN:     kernel stack: 0xffffffff81201000 to 0xffffffff81206000
KERN:       user stack: 0x00007fa87509d000 to 0x00007fa87609d000
KERN: frame                       caller             <image>:function + offset
KERN:  0 ffffffff812052b0 (+  32) ffffffff8014d4d0   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x1a
KERN:  1 ffffffff81205300 (+  80) ffffffff800b4d88   <kernel_x86_64> debug_call_with_fault_handler + 0x78
KERN:  2 ffffffff81205360 (+  96) ffffffff800b6434   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf4
KERN:  3 ffffffff812053b0 (+  80) ffffffff800b67ce   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e
KERN:  4 ffffffff812054a0 (+ 240) ffffffff800b6b67   <kernel_x86_64> panic + 0xb7
KERN:  5 ffffffff812054c0 (+  32) ffffffff8112a911   </boot/system/add-ons/kernel/file_systems/ramfs> Node::~Node[clone .localalias] () + 0xc1
KERN:  6 ffffffff812054e0 (+  32) ffffffff81122c09   </boot/system/add-ons/kernel/file_systems/ramfs> File::~File[clone .localalias] () + 0x39
KERN:  7 ffffffff81205500 (+  32) ffffffff81124589   </boot/system/add-ons/kernel/file_systems/ramfs> ramfs_remove_vnode(fs_volume*, fs_vnode*, bool) + 0x39
KERN:  8 ffffffff81205540 (+  64) ffffffff800fe2a4   <kernel_x86_64> free_vnode(vnode*, bool) + 0xb4
KERN:  9 ffffffff81205590 (+  80) ffffffff800ffa7b   <kernel_x86_64> dec_vnode_ref_count[clone .isra.0] (vnode*, bool, bool) + 0x33b
KERN: 10 ffffffff812055b0 (+  32) ffffffff800eed84   <kernel_x86_64> put_fd + 0x84
KERN: 11 ffffffff812055e0 (+  48) ffffffff80109520   <kernel_x86_64> vfs_put_io_context + 0x80
KERN: 12 ffffffff81205630 (+  80) ffffffff80080734   <kernel_x86_64> BKernel::Team::~Team() + 0x44
KERN: 13 ffffffff81205650 (+  32) ffffffff80080951   <kernel_x86_64> BKernel::Team::~Team() + 0x11
KERN: 14 ffffffff81205670 (+  32) ffffffff80172eb6   <kernel_x86_64> BReferenceable::ReleaseReference() + 0x36
KERN: 15 ffffffff81205730 (+ 192) ffffffff80085c5f   <kernel_x86_64> team_delete_team + 0x30f
KERN: 16 ffffffff81205950 (+ 544) ffffffff8008cb4f   <kernel_x86_64> thread_exit + 0xc2f
KERN: 17 ffffffff81205ef0 (+1440) ffffffff8007569f   <kernel_x86_64> handle_signals + 0x99f
KERN: 18 ffffffff81205f20 (+  48) ffffffff80088f1e   <kernel_x86_64> thread_at_kernel_exit + 0x1e
KERN: 19 ffffffff81205f30 (+  16) ffffffff8014f2d2   <kernel_x86_64> x86_64_syscall_entry + 0x31e
KERN: user iframe at 0xffffffff81205f30 (end = 0xffffffff81205ff8)
KERN:  rax 0x0                   rbx 0x1                   rcx 0x1897fc7e4b9
KERN:  rdx 0x8e75fc6868          rsi 0x884b79b000          rdi 0x1
KERN:  rbp 0x7fa87609bdb0         r8 0x0                    r9 0x1
KERN:  r10 0x2                   r11 0x202                 r12 0x7fa87609bdc8
KERN:  r13 0x10e7ed2c1330        r14 0x6                   r15 0x4
KERN:  rip 0x1897fc7e4b9         rsp 0x7fa87609bd98     rflags 0x202
KERN:  vector: 0x63, error code: 0x0
KERN: 20 00007fa87609bdb0 (+   0) 000001897fc7e4b9   
KERN: 00007fa87609bdb0 -- read fault

[waddlesplash]

I tried to reproduce but didn't manage to. I did manage to find a bunch of ways to hang the system, a number of which I fixed in hrev57924. Does it still reproduce after that?

[diver]

It still does in hrev57924 with the same back trace.

[diver]

Managed to hang the system in different ways simply by launching once or twice.

[waddlesplash]

Managed to reproduce the problem. Fixed in hrev57925. Another cause of hangs fixed in hrev57926. If you can really hang the system in such a way that Team Monitor won't show up and allow you to kill applications, I would be interested in backtraces of what's hung.

[diver]

Doesn't hang or crash anymore. Thanks! :)