This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.25, Windows 7: dumper doesn't generate core file

As a disclaimer I'm new to Cygwin and memory mapping that's alluded to in this post.

My brief was to investigate and resolve an issue with dumper not producing a core.

With that I'll proceed with outlining the journey including my findings so far.

I'll begin with the error message given by dumper when run in verbose mode:
(Note: I modified debug output to provide base address of excluded memory)

$ dumper -d "C:\Program Files (x86)\Airdac 12.6.22\airdac_.exe" 5052
dumping process #5052 to airdac_.exe.core
got debug event 3
excluding section: name= .text base=0x401000 size=00587298
excluding section: name=       .debug_aranges base=0x11b9000 size=00011ce8
excluding section: name= .debug_info base=0x11cb000 size=033c5a4d <== NOTE THIS EXCLUSED SECTION
excluding section: name=         .debug_abbrev base=0x4591000 size=0016413e
added module 0x400000 C:\Program Files (x86)\Airdac 12.6.22\airdac_.exe
got debug event 6
excluding section: name= .text base=0x2b21000 size=00012c1b <== OVERLAPS with EXCLUSION ABOVE?
added module 0x768d0000 C:\Windows\SysWOW64\sechost.dll
got debug event 6
excluding section: name= .text base=0x3321000 size=0000b03c <== OVERLAPS with EXCLUSION ABOVE?
added module 0x73c90000 C:\Windows\system32\napinsp.dll
added memory region 0x400000-0x401000
added memory region 0x988298-0x11b9000
added memory region 0x11cace8-0x11cb000
added memory region 0x4590a4d-0x2b21000 <== Should have been 0x4590a4d-0x4591000 added memory region 0x2b33c1b-0x3321000 <== should NOT have this entry added memory region 0x332c03c-0x4591000 <== should NOT have this entry
added memory region 0x46f513e-0x46f6000
added memory region 0x4950271-0x4951000
writing section type=0 base=0x4590a4d size=0xfe5905b3 flags=00000103
Failed to read process memory at 551aa4d(1000), error 299 <== ERROR HERE
writing section type=0 base=0x2b33c1b size=0x7ed3e5 flags=00000103
writing memory region to bfd: File truncated
writing section type=0 base=0x332c03c size=0x1264fc4 flags=00000103

The 299 error occurs when dumper attempts to read memory region between 0x4590a4d-0x2b21000.

Code analysis reveals a few shortcomings leading up to this failure. Firstly the process of identifying sections to exclude, includes sorting and checking that regions do not overlap. Upon closer inspection the function in question at ...winsup/utils/ appears to
have a couple of problems.

a) "if (q == p + 1)" at line 60 always resolves true bypassing subsequent loop code.

b) The 'size' parameter at line 63 is a global instead of p->size. The test expression should be if (p->base + p->size > q->base) in order to test for overlapping regions.

     55 exclusion::sort_and_check ()
     56 {
     57   qsort (region, last, sizeof (process_mem_region), &cmp_regions);
58 for (process_mem_region * p = region; p < region + last - 1; p++)
     59     {
     60       process_mem_region *q = p + 1;
     61       if (q == p + 1)
     62         continue;
     63       if (p->base + size > q->base)
     64         {
65 fprintf (stderr, "region error @ (%p + %zd) > %p\n", p->base, size, q->base);
     66           return 0;
     67         }
     68     }
     69   return 1;
     70 }

Even if sort_and_check () worked correctly it wouldn't prevent dumper failure it just raises an alert.

Secondly when dumper builds a list of memory regions to dump into a core file it has no logic to cater for overlapping sections to exclude. Here in lies my first question regarding this issue:


It's also worth mentioning these overlapping sections are between the Process and DLL memory regions.

If the answer is no should I proceed drilling into binutils/bfd_map_over_sections source for answers?

If it's permitted then split_add_mem_region(...) function inside of .../winsup/utils/ has no provision to process overlapping memory parts accessed from the "excl_list" array.

As a temporary measure I added a few lines (see CODE ADDITION makers) to bypass overlapping exclusions. With this modification dumper was able to successfully dump a core file which was fully examinable.

217 /* split_add_mem_region scans list of regions to be excluded from dumping process 218 (excl_list) and removes all "excluded" parts from given region. */
    219 int
    220 dumper::split_add_mem_region (LPBYTE base, SIZE_T size)
    221 {
    222   if (!sane ())
    223     return 0;
    225   if (base == NULL || size == 0)
    226     return 1;                   // just ignore empty regions
    228   LPBYTE last_base = base;
    230   for (process_mem_region * p = excl_list->region;
    231        p < excl_list->region + excl_list->last;
    232        p++)
    233     {
    23X       /* skip any overlapping parts */    <== CODE ADDITION
    23X       if (last_base > p->base)               <== CODE ADDITION
23X continue; <== CODE ADDITION
    234       if (p->base >= base + size || p->base + p->size <= base)
    235         continue;
    237       if (p->base <= base)
    238         {
    239           last_base = p->base + p->size;
    240           continue;
    241         }
    243       add_mem_region (last_base, p->base - last_base);
    244       last_base = p->base + p->size;
    245     }
    247   if (last_base < base + size)
    248     add_mem_region (last_base, base + size - last_base);
    250   return 1;
    251 }

On the unexpected possibility excluded regions can overlap my next question follows:


Thinking about it one could also modify sort_and_check(...) to filter out overlaps.

As noted I'm new to the Cygwin paddock so please go easy on this little sheep.

I appreciate any insight and advice anyone can provide to this issue.


Attachment: cygcheck.out
Description: Text document

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]