|
From: Ivo R. <iv...@iv...> - 2015-04-05 09:21:44
Attachments:
coredump_single_thread.c
coredump_single_thread.c
|
I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) causes some form of regression in stack extending. Please see attached test cases for x86/linux and amd64/linux. On Valgrind r15033 these finish successfully with: ==19090== Process terminating with default action of signal 11 (SIGSEGV) ==19090== Access not within mapped region at address 0x101 Segmentation fault (core dumped) (Which is expected behaviour because they test dumping core.) However on Valgrind r15034 these crash Valgrind with an assertion: --19128:0: aspacem Valgrind: FATAL: aspacem assertion failed: --19128:0: aspacem nsegments[segA].kind == SkAnonC --19128:0: aspacem at m_aspacemgr/aspacemgr-linux.c:2845 (vgPlain_am_extend_into_adjacent_reservation_client) --19128:0: aspacem Exiting now. The attached test cases are simply built with gcc -m32/-m64. Kind regards, I. |
|
From: Ivo R. <iv...@iv...> - 2015-04-05 10:25:21
|
2015-04-05 11:21 GMT+02:00 Ivo Raisr <iv...@iv...>: > I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) > causes some form of regression in stack extending. > ... > Bug report: https://bugs.kde.org/show_bug.cgi?id=345887 |
|
From: Julian S. <js...@ac...> - 2015-04-09 11:57:42
|
On 05/04/15 12:25, Ivo Raisr wrote: >> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) >> causes some form of regression in stack extending. >> ... >> > Bug report: > https://bugs.kde.org/show_bug.cgi?id=345887 Austin English (cc'd) was reporting recently, some strange segfault loop phenomenon which might possibly be related. Unfortunately not easily reproducible. 345887 should be pretty simple to track down, though. J |
|
From: Philippe W. <phi...@sk...> - 2015-04-09 19:02:09
|
On Thu, 2015-04-09 at 13:57 +0200, Julian Seward wrote: > On 05/04/15 12:25, Ivo Raisr wrote: > >> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) > >> causes some form of regression in stack extending. > >> ... > >> > > Bug report: > > https://bugs.kde.org/show_bug.cgi?id=345887 > > Austin English (cc'd) was reporting recently, some strange segfault loop > phenomenon which might possibly be related. Unfortunately not easily > reproducible. 345887 should be pretty simple to track down, though. We have already encountered some problems with detecting if/when a stack can be extended. I think VG_(am_is_bogus_client_stack_pointer)() name is somewhat misleading, as this could return True for a fully valid client stack pointer, but that is not in the 'extensible stack' but e.g. in a non extensible pthread stack. We should rename it e.g. to VG_(am_addr_is_in_extensible_stack_segment)() or something like that. And then we have to be sure it is called before any call to extend stack : after a quick look at 345887, we have at least one missing place. Philippe |
|
From: Florian K. <fl...@ei...> - 2015-04-09 19:59:03
|
On 09.04.2015 21:02, Philippe Waroquiers wrote: > On Thu, 2015-04-09 at 13:57 +0200, Julian Seward wrote: >> On 05/04/15 12:25, Ivo Raisr wrote: >>>> I think r15034 (changes adding VG_(am_is_bogus_client_stack_pointer)()) >>>> causes some form of regression in stack extending. >>>> ... >>>> >>> Bug report: >>> https://bugs.kde.org/show_bug.cgi?id=345887 >> >> Austin English (cc'd) was reporting recently, some strange segfault loop >> phenomenon which might possibly be related. Unfortunately not easily >> reproducible. 345887 should be pretty simple to track down, though. > We have already encountered some problems with detecting if/when > a stack can be extended. > I think VG_(am_is_bogus_client_stack_pointer)() name is somewhat > misleading, as this could return True for a fully valid client stack > pointer, but that is not in the 'extensible stack' but e.g. in a > non extensible pthread stack. > > We should rename it e.g. to > VG_(am_addr_is_in_extensible_stack_segment)() > or something like that. > > And then we have to be sure it is called before any call to > extend stack : after a quick look at 345887, we have at > least one missing place. I've seen it but won't have time to look at it this week. I'm away until Sunday. There are several places that are possibly missed. I think (not sure) the reason for the recent failure is that VG_(extend_stack) is not as permissive as it used to be. It believes pretty much that the passed in address is in a stack segment or in a neighbouring RESVN segment. That makes sense given the function name but.... If you want to beat me at it feel free to do so :) Florian > > Philippe > > > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Philippe W. <phi...@sk...> - 2015-04-09 20:03:07
|
On Thu, 2015-04-09 at 21:58 +0200, Florian Krohm wrote: > If you want to beat me at it feel free to do so :) This crashes in a very special case, no urgency :) Philippe |
|
From: Ivo R. <iv...@iv...> - 2015-04-12 19:45:03
|
2015-04-09 22:03 GMT+02:00 Philippe Waroquiers < phi...@sk...>: > On Thu, 2015-04-09 at 21:58 +0200, Florian Krohm wrote: > > If you want to beat me at it feel free to do so :) > This crashes in a very special case, no urgency :) > I have a patch including test cases ready for review in https://bugs.kde.org/show_bug.cgi?id=345887 After all, it was not so difficult. I. |