KDL while on Youtube (crash in common_poll())

[DaaT]

Updated my installation last night and after was testing Web+. Went to youtube and while playing/pausing a video in full screen (well, Haiku's full screen), I got sent on a trip to KDL. I'll attach a photo of the stack trace.

[pulkomandy]

Probably another case of running a syscall on an already deleted socket. This time the crash is in common_poll() called by BAbstractSocket::WaitForReadable() (info available in the KDL screenshot, just making it more easily searchable)

[ttcoder]

Just occured here on hrev47972. Thought of doing a disthis time; here goes in case it's of use/interest to someone. Editing title as I had trouble finding this ticket.. PS - the "-b" syntax should be exposed in KDL help, and wondering what command to use to "flush" the KDL session to previous_syslog..

write access attempted on write-protected area 0x53 at 0xdeadb000
vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0xdeadbef7, ip 0x8008e55e, write 1, user 0, thread 0xd01
PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbef7, ip 0x8008e55e

Welcome to Kernel Debugging Land...
Thread 3329 "BUrlProtocol.HTTP" running on CPU 1
stack trace for thread 3329 "BUrlProtocol.HTTP"
    kernel stack: 0x81efc000 to 0x81f00000
      user stack: 0x7960b000 to 0x7964b000
frame               caller     <image>:function + offset
 0 81effc94 (+  32) 801422c6   <kernel_x86> arch_debug_stack_trace + 0x12
 1 81effcb4 (+  16) 800a21bf   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 81effcc4 (+  12) 8013408e   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 81effcd0 (+  48) 800a3d2a   <kernel_x86> debug_call_with_fault_handler + 0x5a
 4 81effd00 (+  64) 800a23db   <kernel_x86> kernel_debugger_loop([34m0x80185c97[0m [36m"PANIC: "[0m, [34m0x8019c700[0m [36m"vm_page_fault: unhandled page fault in kernel space at 0x%lx, ip 0x%lx

 5 81effd40 (+  48) 800a2757   <kernel_x86> kernel_debugger_internal([34m0x80185c97[0m [36m"PANIC: "[0m, [34m0x8019c700[0m [36m"vm_page_fault: unhandled page fault in kernel space at 0x%lx, ip 0x%lx

 6 81effd70 (+  48) 800a40b2   <kernel_x86> panic + 0x3a
 7 81effda0 (+ 144) 80118c9d   <kernel_x86> vm_page_fault + 0x149
 8 81effe30 (+  80) 80143aeb   <kernel_x86> x86_page_fault_exception + 0x177
 9 81effe80 (+  12) 80136a4c   <kernel_x86> int_bottom + 0x3c
kernel iframe at 0x81effe8c (end = 0x81effedc)
 eax 0xdeadbeef    ebx 0x0            ecx 0x828043a4  edx 0x828043b4
 esi 0x0           edi 0xf1203ed0     ebp 0x81efff04  esp 0x81effec0
 eip 0x8008e55e eflags 0x13286   
 vector: 0xe, error code: 0x2
10 81effe8c (+ 120) 8008e55e   <kernel_x86> common_poll(pollfd*: [34m0xf1203ed0[0m, uint32: [34m0x1[0m ([34m1[0m), int64: [34m-1511828489000[0m, [34mfalse[0m) + 0x96
11 81efff04 (+  64) 8008f108   <kernel_x86> _user_poll + 0x138
12 81efff44 (+ 100) 80136c4f   <kernel_x86> handle_syscall + 0xdc
user iframe at 0x81efffa8 (end = 0x81f00000)
 eax 0x7d          ebx 0x3a6144       ecx 0x79648fdc  edx 0x61686114
 esi 0xfffffcd8    edi 0xfffffe9f     ebp 0x79649018  esp 0x81efffdc
 eip 0x61686114 eflags 0x3202    user esp 0x79648fdc
 vector: 0x63, error code: 0x0
13 81efffa8 (+   0) 61686114   <commpage> commpage_syscall + 0x04
14 79649018 (+  64) 0102e223   <libbnetapi.so> BAbstractSocket<[32m0x1b49da48[0m>::_WaitFor const(int32: [34m1[0m, int64: [34m9223372036854775807[0m) + 0x85
15 79649058 (+  32) 0102e27a   <libbnetapi.so> BAbstractSocket<[32m0x1b49da48[0m>::WaitForReadable const(int64: [34m9223372036854775807[0m) + 0x22
16 79649078 (+4272) 01038cda   <libbnetapi.so> BHttpRequest<[32m0x1e776510[0m>::_MakeRequest() + 0x202
17 7964a128 (+ 240) 010398b7   <libbnetapi.so> BHttpRequest<[32m0x1e776510[0m>::_ProtocolLoop() + 0x195
18 7964a218 (+  32) 0103fabf   <libbnetapi.so> BUrlRequest<[32m0x1e776510[0m>::_ThreadEntry(void*: NULL) + 0x1f
19 7964a238 (+  32) 002fea32   <libroot.so> _thread_do_exit_work (nearest) + 0x8b
20 7964a258 (+   0) 61686250   <commpage> commpage_thread_exit + 0x00
kdebug> kdebug> kdebug> dis[34m0x8008e55e: c744180800100000	mov $0x1000, 0x8(%eax,%ebx)
[m0x8008e566:   66c744f7060010	movw $0x1000, 0x6(%edi,%esi,8)
0x8008e56d:         c645f701	movb $0x1, -0x9(%ebp)
0x8008e571:               46	inc %esi
0x8008e572:           3b750c	cmp 0xc(%ebp), %esi
0x8008e575:             7289	jb 0x8008e500
0x8008e577:         807df700	cmpb $0x0, -0x9(%ebp)
0x8008e57b:             752e	jnz 0x8008e5ab
0x8008e57d:           83c4f4	add $0xf4, %esp
0x8008e580:           8b5510	mov 0x10(%ebp), %edx
kdebug> cowrite access attempted on write-protected area 0x53 at 0xdeadb000
vm_page_fault: vm_soft_fault returned error 'Permission denied' on fault at 0xdeadbef7, ip 0x8008e55e, write 1, user 0, thread 0xd01

[mmlr]

Fixed in hrev48100.

[mmlr]

(In #10763) Fixed in hrev48100.

[mmlr]

(In #10230) Fixed in hrev48100.

[mmlr]

(In #10694) Replying to ttcoder:

While hrev48100 is still 'fresh' in our minds, maybe someone can give a quick glance to the common_wait_for_objects() reference here, maybe it's the same that was fixed by Michael in 48100 and this ticket is a duplicate..

Indeed it is. Thanks for the heads up!

[waddlesplash]

Quick paste of IRC backlog about closing things as duplicates of this:

<mmlr> as a reminder: 0xdeadbef7 is just 0xdeadbeef + 8
<mmlr> many places accessing freed memory may run into "0xdeadbeef + 8" if they access freed memory with an offset of 8
<mmlr> more precisely it's an 0xdeadbef7 in common_poll, common_select or common_wait_for_object
<mmlr> if you find more bugs with such a trace, please close them as a duplicate of #11098
<mmlr> some only have the backtrace in a photo and nothing transcribed in the summary, so it's quite hard to find them