The memPort pointer has value 0x6 which is not a real address. It ultimately probably came from a member variable of a structure or class which was pointed to with a NULL pointer, or it could ust be a junk address. You should figure out where memPort is coming from and that might lead to the real problem.
How have you determined it's not your code if you haven't found the source of the problem? Gabe On 03/30/11 10:27, Griffin Wright wrote: > Gabe et al: > > So I've determined that these various issues (segfaults, > system.cpu:locked not being unserializable, and the warning about > system.cpu.workload: M5_pid not being present) are not the result of > any code modifications that I've made. > > Focusing on the segfault, which occurs when I try to restore a > checkpoint made while using simple atomic (and using the same to do > the restoration), the following is the gdb trace I get, accompanied by > a few gdb commands. I'm not a debugging expert, and am not sure what > to make of all of this aside from it seeming like a segfault when > trying to load a 'section' back into memory. > > -Griffin Wright > ------------------------------------- > > M5 compiled Mar 29 2011 19:01:25 > M5 revision 31a04e5ac4be+ 7866+ default tip > M5 started Mar 30 2011 10:13:44 > M5 executing on grwright-desktop > > command line: /home/grwright1/Research/m5/build/ARM_SE/m5.debug > configs/SFI/sfi_test.py --at-instruction --checkpoint-restore=100 > > Running Simulation now > Global frequency set at 1000000000000 ticks per second > 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 > * > warn: optional parameter system.cpu.workload:M5_pid not present* > > For more information see: http://www.m5sim.org/warn/aa78cda1 > **** REAL SIMULATION **** > > *Program received signal SIGSEGV, Segmentation fault. > 0x08d25d6b in ObjectFile::loadSection (this=0x94a4ed0, sec=0x94a4efc, > memPort=0x6, addrMask=18446744073709551615) at > build/ARM_SE/base/loader/object_file.cc:75 > 75 memPort->writeBlob(addr, sec->fileImage, sec->size);* > > (gdb) list > 70 ObjectFile::loadSection(Section *sec, Port *memPort, Addr > addrMask) > 71 { > 72 if (sec->size != 0) { > 73 Addr addr = sec->baseAddr & addrMask; > 74 if (sec->fileImage) { > 75 memPort->writeBlob(addr, sec->fileImage, sec->size); > 76 } > 77 else { > 78 // no image: must be bss > 79 memPort->memsetBlob(addr, 0, sec->size); > > (gdb) print addr > $1 = 32768 > (gdb) print sec->size > $2 = 519500 > (gdb) print sec->fileImage > $3 = (uint8_t *) 0x97bd8000 "\177ELF\001\001\001" > > > > On 3/29/2011 2:04 PM, Gabe Black wrote: >> The M5_pid warning is possibly the symptom of a bug since I would expect >> the same build of the simulator to serialize and then unserialize it >> symmetrically, not just to unserialize it. Basically, it's a way to >> force the pid assigned to the simulated process which can be returned by >> certain system calls. There are circumstances where that's useful, but >> it should be harmless for you. >> >> M5 should never get a segfault (other than the simulated kind) so that >> part is a more serious bug. Please let us know what you find, >> particularly if you haven't modified any code. >> >> Gabe > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
