Hardware watchpoint 2: *(0xbfffcb5c) Old value = -987698962 New value = -987699200 DFANIgetann (filename=0x8125d10 "tdfanF.hdf", tag=<value optimized out>, ref=<value optimized out>, ann=0xbfffcb3e "Object label #1: sds ", maxlen=31, type=0) at dfan.c:1103 1103 Lastref = annref; /* remember ref last accessed */ Current language: auto; currently c (gdb) list 1098 HCLOSE_GOTO_ERROR(file_id,DFE_READERROR,FAIL); 1099 } 1100 if (type == DFAN_LABEL) 1101 ann[annlen] = '\0'; /* terminate string properly */ 1102 1103 Lastref = annref; /* remember ref last accessed */ (gdb) print &ann[annlen] $7 = (uint8 *) 0xbfffcb5c "" So that's where I get clobbered. Need to figure out why, but at least I solved the watch location question.
Because this is a trap which happens AFTER the damage has been done, then the location identified (line 1103) is the NEXT point of execution. The damage was done one [dynamic] statement prior, in this case line 1101: ann[annlen] = '\0'; This can be corroborated by looking at the watch values in hex: (gdb) set output-radix 16 (gdb) p -987698962 $1 = 0xc520e8ee (gdb) p -987699200 $2 = 0xc520e800 ### low byte set to '\0' -- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
