Bug #536
closedSavecore broken?
0%
Description
I'm running the latest -DEVEL world/kernel built with gcc41. I'm
seeing a kernel panic when trying mount_smbfs, so I've been trying
to get a crashdump to send you.
- savecore /var/crash
savecore: /kernel: _dumpmag not in namelist
Anyone else seeing this?
Updated by bastyaelvtars almost 18 years ago
On Wed, 24 Jan 2007 06:04:37 -0800
walt <wa1ter@myrealbox.com> wrote:
Me.
--
Gergo Szakal <bastyaelvtars@gmail.com>
University Of Szeged, HU
Faculty Of General Medicine
/* Please do not CC me with replies, thank you. */
Updated by wa1ter almost 18 years ago
On Wed, 24 Jan 2007, Simon 'corecode' Schubert wrote:
Thanks. Now, do you want the crashdump I finally got? :o)
The panic is 100% reproducible on my end.
Updated by dillon almost 18 years ago
:> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> added the comment:
:>
:> fixed
:
:Thanks. Now, do you want the crashdump I finally got? :o)
:The panic is 100% reproducible on my end.
Sure. I am putting in the journaling fixes and branching though, it
can't be held off any longer, so any bug fix(es) will have to be
committed to both branches.
-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by wa1ter almost 18 years ago
On Thu, 25 Jan 2007, Matthew Dillon wrote:
Okay, the files are in my crash directory on leaf. I also gave you my
libiconv, libmchain, and smbfs kernel modules because they have to be
loaded in order to use mount_smbfs. For future reference, do you really
need those kernel modules to do your debugging?
Thanks.
Updated by corecode almost 18 years ago
always. they are part of the kernel and equally important.
cheers
simon
Updated by dillon almost 18 years ago
:Okay, the files are in my crash directory on leaf. I also gave you my
:libiconv, libmchain, and smbfs kernel modules because they have to be
:loaded in order to use mount_smbfs. For future reference, do you really
:need those kernel modules to do your debugging?
:
:Thanks.
Ok, here is the backtrace:
at /usr/src/sys/platform/pc32/i386/trap.c:1085
#8 0xc02b9748 in trap_pfault (frame=0xcefecab8, usermode=0, eva=6)
at /usr/src/sys/platform/pc32/i386/trap.c:991
#9 0xc02b9c68 in trap (frame=0xcefecab8)
at /usr/src/sys/platform/pc32/i386/trap.c:674
#10 0xc02abc36 in calltrap ()
at /usr/src/sys/platform/pc32/i386/exception.s:783
#11 0xc0290de7 in strcmp (s1=0xcefecb28 "xlat",
s2=0x6 <Address 0x6 out of bounds>) at /usr/src/sys/libkern/strcmp.c:48
#12 0xced388f3 in iconv_sysctl_add (oidp=0xced392c0, arg1=0x0, arg2=0,
req=0xcefecbf0) at /usr/src/sys/libiconv/iconv.c:146
#13 0xc019a5fa in sysctl_root (oidp=Variable "oidp" is not available.
) at /usr/src/sys/kern/kern_sysctl.c:1194
#14 0xc019a70d in userland_sysctl (name=0xcefecc78, namelen=3, old=0xbfbfef9c,
oldlenp=0xbfbfef98, inkernel=0, new=0xbfbfefa0, newlen=108,
---Type <return> to continue, or q <return> to quit---q
I think it may be bounds checking on the iconv_add_in structure.
Please try this patch. If it doesn't work we will need to add more
debugging there to figure out why it is failing.
-Matt
Matthew Dillon
<dillon@backplane.com>
Index: libiconv/iconv.c
===================================================================
RCS file: /cvs/src/sys/libiconv/iconv.c,v
retrieving revision 1.5
diff u -r1.5 iconv.c libiconv/iconv.c 5 Sep 2006 00:55:46 -0000 1.5
--
++ libiconv/iconv.c 26 Jan 2007 18:50:41 -0000@ -354,6 +354,11
@
return EINVAL;
if (din.ia_datalen > ICONV_CSMAXDATALEN)
return EINVAL;
+ din.ia_converter[ICONV_CNVNMAXLEN-1] = 0;
+ din.ia_to[ICONV_CSNMAXLEN-1] = 0;
+ din.ia_from[ICONV_CSNMAXLEN-1] = 0;
+
if (iconv_lookupconv(din.ia_converter, &dcp) != 0)
return EINVAL;
error = iconv_register_cspair(din.ia_to, din.ia_from, dcp, NULL, &csp);
Updated by wa1ter almost 18 years ago
Matthew Dillon wrote:
Sorry, the panic is exactly the same. :o(
Updated by swildner almost 16 years ago
Walt,
do you still have this smbfs problem or can we close this issue?
Updated by tuxillo almost 15 years ago
Hi,
iconv was a bit reworked recently and the dumping system has been refactored. Is
this still happening? Please, provide some feedback.
Cheers,
Antonio Huete