I've found that when I try to debug a multithreaded program (with ddd and/or
gdb plus linuxthreads support) and threads get created or destroyed (sending
sigusr1 & 2), or if my multithreaded program SEGVs, smbfs does the
following...
Apr 21 13:24:46 olympus kernel: smb_request: len = 53 cmd = 0x22
Apr 21 13:24:46 olympus kernel: smb_receive_raw: recvfrom error = 512
Apr 21 13:24:46 olympus kernel: smb_get_length: recv error = 512
Apr 21 13:24:46 olympus kernel: smb_request: result -512, setting invalid
Apr 21 13:24:46 olympus kernel: smb_invalidate_inodes
Apr 21 13:24:46 olympus kernel: smb_close_dentry: closed src/TestHarness,
count=1
Apr 21 13:24:46 olympus kernel: smb_close_dentry: closed //src, count=1
Apr 21 13:24:46 olympus kernel: smb_request: result = -512
Apr 21 13:24:46 olympus kernel: smb_request failed
Apr 21 13:24:46 olympus kernel: smb_close_socket: closing socket d51f4c4c
Apr 21 13:24:46 olympus kernel: smb_retry: signalled pid 0, waiting for new
connection
Apr 21 13:24:46 olympus kernel: smb_retry: caught signal
... and another 10 or so signals caught - presumably one per thread
which of course sig's smbmount to attempt reconnect, which as we've
discovered only works if the password has been given either on the command
line or in an environment variable (both of which I am rather uncomfortable
with).
We are doing extensive cross-platform development for Linux/Win32 over smbfs
and this is giving us nightmares.
Why would smbfs care about signals sent to a user space, multithreaded
process? or am I missing the point?
regards,
Paul Archard
Lead Software Engineer
Workfire Development Corporation
Kelowna, BC, Canada
http://www.workfire.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/