[lug] (no subject)

[D. Stimits]

"Abdul khadar K.A." wrote:
> 
> hi ,
> I'm using Samba 2.2.1a to access files in a floppy drive , from a windows
> node.
> when being  run on top of redhat6.2 with kernel version  2.4.0   ,
> supermount 5.3 is showing problems while
> saving files which crearte temporary files on the Linux floppy device .  (
> Especially software's
> like MS-WORD , excel etc. ).
> 
> The Error shown is segmentation fault.
> 
> we were able to pin point the place where this error occured and three
> routines viz.
> 
> inline void update_nlink(struct inode *superi, struct inode *subi);
> inline void update_ctime(struct inode *superi, struct inode *subi);
> inline void update_mtime(struct inode *superi, struct inode *subi);
> 
> the pointer to structure passed on to this routine happens to be a null
> pointer , when this
> error occurs.  I put a check for null pointer and i was able to minimize
> errors.
> 
> My question is as follows
> 
>   Can pointer to struct inode *  be a null pointer ? or was it due to some
> other error ?
> 

Many programmers consider any pointers should always be assigned null
upon declaration, to catch later errors. And to assign null after
release of memory, so that pointers won't be accidentally reused once
deallocated. In C, and C++ if new_handler is using old style
assignments, memory allocation failures also return null. So it is an
error to use a struct inode * which is null, but how it became null is
only an error if memory allocation failure caused it. In other cases, it
was just good housekeeping as a way to help debug something exactly like
what you just found. If your segmentation fault produced a core dump, or
if you can run the seg fault app in gdb, and upon failure, take a stack
frame (backtrace, simply type "bt"), you might find out a lot about the
source, such as whether it was in an malloc call. The big problem here
is that if your seg faulting app is not compiled with debugging symbols,
all you will get are hex address dumps. There is a possibility you'll
get something useful even without symbols, so try this if you have core,
regardless of symbols:
gdb -c core
(do from where the core dump occurred)

If that doesn't help, you'll have to recompile with debugging symbols
(-g option, and -Ox turned off).

D. Stimits, stimits at idcomm.com