Darshan-users

Download

[email protected]

December 2017

3 participants
2 discussions

Bad data in file headers
by Ed Karrels 03 Dec '17

03 Dec '17

On Fri, 2017-12-01 at 11:24 -0500, Phil Carns wrote: > Hi Ed, > > I don't think we've seen this particular error before. Is it also > the same application/executable every time in addition to being the > same user in each case? Yep, same application, "pcp". Not sure why I missed these cases before, but there are other users running this application, and each of their darshan3 files have the same errors. So it seems to be the application, not the user. Rob Latham: > Is there any chance darshan2 tools are trying to operate on darshan3 > files? I hate to offer such an obvious suggestion, but you have > generated both log formats so at some point in time you had darshan2 > tooling lying around. Any darshan2 libraries or tools are probably > long gone by now but I wanted to rule out the obvious. I don't think so. All the darshan2 files have ".darshan.gz" as their filename suffix and the first few bytes are a gzip header: 1F 8B 08 00 These files have ".darshan" as their filename suffix, and the header starts with "3.10". $ head -c 64 logtree/00/2f/heitz_pcp_id7666317_10-15-53224-12998966924006311962_1.darshan | hexdump 000000: 33 2E 31 30 00 00 00 00 37 35 64 00 00 00 00 00 3.10....75d..... 000010: 00 00 00 00 00 00 00 00 FB 01 00 00 00 00 00 00 ................ 000020: 05 FE FF FF FF FF FF FF 00 00 00 00 00 00 00 00 ................ 000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

2 1

Bad data in file headers
by Ed Karrels 01 Dec '17

01 Dec '17

I'm scanning through Darshan logs from Blue Waters, and darshan-parser fails on bunch (1588) of log files. They're all Darshan version 3 files, and all from the same user. Every one of this user's Darshan version 3 files fails. Their Darshan version 2 files are fine. I ran darshan-parser in a debugger, and found that the headers seem to have a couple garbage entries. After the call to darshan_log_get_job(), the "len" fields in fd->name_map and fd->mod_map[6] seem to be invalid: (gdb) p /x fd->name_map $42 = {off = 0x1fc, len = 0xfffffffffffffe04} (gdb) p /x fd->mod_map[6] $43 = {off = 0x277, len = 0xfffffffffffffd89} Have you seen errors like these before? Any idea why they're happening? Since it's only one user, I suspect it's something in their code, perhaps a failure during MPI_Finalize.

3 2