Stack Overflow in GEOM

From: Cy Schubert <Cy.Schubert_at_komquats.com>
Date: Tue, 16 Apr 2013 10:56:31 -0700
Has anyone see this before? Just updated my CURRENT partitions on my 
testbed and laptop. The laptop just boots but I've managed to capture this 
on my testbed (attached to a serial port on another system).

This is HEAD from yesterday (Apr 15) morning (PDT). The partition being 
booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is there a 
way to quickly display that kern.kstack_pages from DDB?

ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: <SAMSUNG SP0802N TK100-24> ATA-7 device
ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
ada1 at ata0 bus 0 scbus0 target 1 lun 0
ada1: <Maxtor 6Y120P0 YAR41BW0> ATA-7 device
ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes)
ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C)
ada1: Previously was known as ad1
ada2 at ata2 bus 0 scbus2 target 0 lun 0
ada2: <WDC WD5000AAKS-00D2B0 12.01C02> ATA-8 SATA 2.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C)
ada2: Previously was known as ad4
ada3 at ata3 bus 0 scbus3 target 0 lun 0
ada3: <WDC WD3200KS-00PFB0 21.00M21> ATA-7 SATA 2.x device
ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes)
ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C)
ada3: Previously was known as ad6
SMP: AP CPU #1 Launched!
panic: stack overflow detected; backtrace may be corrupted
cpuid = 1
KDB: enter: panic
[ thread pid 13 tid 100009 ]
Stopped at      kdb_enter+0x3d: movl    $0,kdb_why
db> bt
Tracing pid 13 tid 100009 td 0x872d6000
kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at 
kdb_enter+0x3d/frame 0x86edca98
panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at 
panic+0x141/frame 0x86edcad4
__stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at 
__stack_chk_init/frame 0x86edcae0
g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at 
g_label_disk_ident_taste+0x102/frame 0x86edcb70
g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at 
g_label_taste+0x3ca/frame 0x86edcc6c
g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at 
g_new_provider_event+0xb1/frame 0x86edcc88
g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at 
g_run_events+0x19f/frame 0x86edccc4
fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4
fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4
--- trap 0, eip = 0, esp = 0x86edcd40, ebp = 0 ---
db> 

I've been poking at this off and on last night. Any ideas?


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org
Received on Tue Apr 16 2013 - 15:56:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:36 UTC