[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #19473] Running a fatfs translator on a node N can crash the file s

From: Thomas Schwinge
Subject: [bug #19473] Running a fatfs translator on a node N can crash the file system server where N is on
Date: Fri, 30 Mar 2007 18:14:59 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061201 Firefox/ (Ubuntu-feisty)


                 Summary: Running a fatfs translator on a node N can crash
the file system server where N is on
                 Project: The GNU Hurd
            Submitted by: tschwinge
            Submitted on: Friday 03/30/07 at 20:14
                Category: Hurd Servers
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Reproducibility: Every Time
              Size (loc): None
         Planned Release: None
                  Effort: 0.00
Wiki-like text discussion box: 



The current Debian-shipped fatfs translator doesn't work.  I got a statically
linked one to work.  However, the current `/hurd/fatfs' will, when run on a
node N, crash the file system server where N is on.  It goes like this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
[Switching to thread 459.10]
0x010f8000 in _hurd_intr_rpc_msg_sp_restored () from /lib/libc.so.0.3
(gdb) bt
#0  0x010f8000 in _hurd_intr_rpc_msg_sp_restored () from /lib/libc.so.0.3
#1  0x01273768 in fsys_getroot () from /lib/libhurduser.so.0.3
#2  0x0105f4ea in fshelp_fetch_root (box=0x8065cec, cookie=0x805ef18,
dotdot=37, user=0x805eec0, flags=64, 
    callback1=0x1037d10 <short_circuited_callback1.10167>,
callback2=0x104dbf0 <_diskfs_translator_callback2_fn>, retry=0x132df74, 
    retryname=0x132df7c "", root=0x132e380) at
#3  0x0103844e in diskfs_S_dir_lookup (dircred=0x805ee68, path=0x132bf5c "b",
flags=<value optimized out>, mode=0, retry=0x132df74, 
    retryname=0x132df7c "", returned_port=0x132e380,
#4  0x01040cab in _Xdir_lookup (InHeadP=0x132bf40, OutHeadP=0x132df50) at
#5  0x0103e9ad in diskfs_fs_server (InHeadP=0x132bf40, OutHeadP=0x805d618) at
#6  0x0103719e in diskfs_demuxer (inp=0x132bf40, outp=0x132df50)
#7  0x010aedfd in internal_demuxer (inp=0x132bf40, outheadp=0x132df50)
#8  0x010dcd32 in mach_msg_server_timeout () from /lib/libc.so.0.3
#9  0x010aeb84 in thread_function.7379 () at
#10 0x010a892d in cthread_body (self=0x8066c70) at
#11 0x00000000 in ?? ()
(gdb) x/5i $pc
0x10f8000 <_hurd_intr_rpc_msg_sp_restored+977>: mov    (%edi),%eax
0x10f8002 <_hurd_intr_rpc_msg_sp_restored+979>: inc    %esi
0x10f8003 <_hurd_intr_rpc_msg_sp_restored+980>: add    $0x4,%edi
0x10f8006 <_hurd_intr_rpc_msg_sp_restored+983>: mov    %eax,0x4(%esp)
0x10f800a <_hurd_intr_rpc_msg_sp_restored+987>: mov    0xffffffbc(%ebp),%ecx
(gdb) info registers 
eax            0x2      2
ecx            0x11     17
edx            0x805d618        134600216
ebx            0x124067c        19138172
esp            0x132aaa4        0x132aaa4
ebp            0x132ab0c        0x132ab0c
esi            0x1      1
edi            0x25     37
eip            0x10f8000        0x10f8000
eflags         0x10202  [ IF RF ]
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x1f     31
gs             0x1f     31


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]