Similar /core file was found on few other computers 
which uses smbmount to mount disk.
The problem seems happens when connection is lost.

The problem exists in samba-2.0.8-0.7
The binary is without debugging symbols so not that useful

#0  0x804b097 in chroot ()
(gdb) bt
#0  0x804b097 in chroot ()
#1  0xbfffe180 in ?? ()
#2  0x804b5a7 in chroot ()
#3  0x804bde9 in chroot ()
#4  0x4008af31 in __libc_start_main (main=0x804bbd0 <chroot+4936>, argc=5, 
    ubp_av=0xbffffab4, init=0x8049e70 <_init>, fini=0x807208c <_fini>, 
    rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffaac)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

This works just fine for me... no coredumps after invalidating the share (samba
server, mounted on a linux client). If you can reproduce it with a system all
current erratas replied, with specific instructions on how to reproduce it.

I can reproduce it on RedHat 7.0 with all updates applied. samba-2.0.8-1.7
It is hard to tell exactly when it dumps core,
but I get a new file /core about 2-3 times a week,
probably when connection fails. 

gdb smbmount /core 
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Core was generated by `smbmount //127.0.0.1/hd /home/hd -o username mal uid mal
port 53123'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libpam.so.0...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x804b097 in chroot ()
(gdb) bt
#0  0x804b097 in chroot ()
#1  0xbfffe1a0 in ?? ()
#2  0x804b5a7 in chroot ()
#3  0x804bde9 in chroot ()
#4  0x40089f31 in __libc_start_main (main=0x804bbd0 <chroot+4936>, argc=5, 
    ubp_av=0xbffffad4, init=0x8049e70 <_init>, fini=0x807205c <_fini>, 
    rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffacc)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

I have 3 computers (all are RedHat 7.0)
with all patches applies.
On all of them I find a /core file from smbmount 
with the trace above.

A trace with debugging symbols

#0  send_fs_socket (service=0x808a260 "\\\\127.0.0.1\\hd", 
    mount_point=0xbfffe9e0 "/home/hd", c=0x80975a8) at client/smbmount.c:308
308			conn_options.fd = c->fd;
(gdb) bt
#0  send_fs_socket (service=0x808a260 "\\\\127.0.0.1\\hd", 
    mount_point=0xbfffe9e0 "/home/hd", c=0x80975a8) at client/smbmount.c:308
#1  0x804b567 in init_mount () at client/smbmount.c:469
#2  0x804bda9 in main (argc=5, argv=0xbffffa84) at client/smbmount.c:681
#3  0x4008af31 in __libc_start_main (main=0x804bb90 <main>, argc=5, 
    ubp_av=0xbffffa84, init=0x8049e38 <_init>, fini=0x807200c <_fini>, 
    rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffa7c)
    at ../sysdeps/generic/libc-start.c:129

For what it worth: the client is samba-2.0.8-1.7 on RedHat 7.0
the server is samba-2.0.5a-1.5.2 on RedHat 5.2
The SMB connection is open via ssh tunnel.
The /core file is created on the client (RedHat 7.0 machine)
when the SSH tunnel gets closed.

Another trace.

#0  send_fs_socket (service=0x808a260 "\\\\127.0.0.1\\hd", 
    mount_point=0xbfffea00 "/home/hd", c=0x80975a8) at client/smbmount.c:308
308			conn_options.fd = c->fd;
(gdb) bt
#0  send_fs_socket (service=0x808a260 "\\\\127.0.0.1\\hd", 
    mount_point=0xbfffea00 "/home/hd", c=0x80975a8) at client/smbmount.c:308
#1  0x804b567 in init_mount () at client/smbmount.c:469
#2  0x804bda9 in main (argc=5, argv=0xbffffaa4) at client/smbmount.c:681
#3  0x4008af31 in __libc_start_main (main=0x804bb90 <main>, argc=5, 
    ubp_av=0xbffffaa4, init=0x8049e38 <_init>, fini=0x807200c <_fini>, 
    rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffa9c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 

The problem still exists in samba-2.0.10-0.7
It is 100% reproduceable
To reproduce:

1. Login from a client machine to a server
	via openssh, open the tunnel:
ssh -L 53123:localhost:139 user.com

2. Mount a share on a client machine

smbmount //localhost/share /mnt -o username=user,uid=user_id,port=53123

3. do 

ls -l /mnt

You will see directory listing

4. Kill the openssh tunnel (just close that terminal)
and then do

ls -l /mnt
ls: /mnt: Input/output error

Now in / you have a core file.

Also note, that smbmount does not 
re-establish mounting after the connection is re-established
It was fixed at some time, but now the problem is back.
This is another bug which is reported at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=19623

I've verified that 2.2.1a-3 doesn't have this behavious, and actually will
reestablish the connection if you restart the ssh tunnel.