To answer your last question ... I have been unfortunately too busy to do any testing myself. But I will note this:
>#1 0x000055555556b2dc in memcpy (__len=8192, >__src=<optimized out>, __dest=0x7fffffff9da0) at >/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29 It is unfortunate that src is optimized out, but that would be coming nsc->ns_inptr so that does track in nsc getting clobbered. >I have worked on debugging this. At some point, the entire nsc >structure becomes garbage. I have not yet pinpointed where memory gets >corrupted. Is it possible to set a watchpoint on some part of the nsc structure? If you ARE overrunning malloc()d data, maybe use a debug malloc library? MacOS X comes with gmalloc which puts a "guard" area at the beginning and end of malloc()d memory which catches when you get overflows. I am not sure what kinds of things are available across Linux distributions. --Ken
