This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [patch 1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]


On 20.08.2014 20:24, Jan Kratochvil wrote:
> On Wed, 20 Aug 2014 16:07:58 +0200, Keven Boell wrote:
>> Finally I was able to reproduce the crash in some of the VLA tests when
>> compiling with -fsanitize=address on FC20 32bit.
>> I've pushed a fix to
>> 	https://github.com/intel-gdb/vla/tree/vla-fortran
>>
>> Let me know if this works for you now. At least on my FC20 32bit system it does
>> not crash anymore.
> 
> I find this fix probably unrelated (as it is a completely different code) to
> the internal error (formerly silent crash).

This prevents the crash I had on my F20 32bit box in f-typeprint.c when compiling with
-fsanitize=address.  The crash occurred in one of our tests.  The other crashes you
reported I'm unfortunately still not able to reproduce (tried different gcc versions, 32/64bit).
Since it seems that your environment differs from a clean FC20, it is hard for me to
reproduce and debug the issues you observe.
E.g. if I try to execute your compiled GDB on FC20 32bit, I get errors that some
shared libraries are missing (e.g. libbabeltrace.so.1).
So I wonder how we should go on from here?

> 
> Tested 15f4f87976493f6e144a9bdb5eb7f0109543a393:
> 
> runtest gdb.fortran/dynamic-other-frame.exp
> [...]
> (gdb) bt^M
> #0  0x000000000040071d in bar_ ()^M
> #1  0x00000000004006c7 in foo (string=gdbtypes.c:2009: internal-error: dynamic_prop_get_const_val_ptr: Assertion `prop->kind == PROP_CONST' failed.^M
> A problem internal to GDB has been detected,^M
> 
> Fedora {20,21} {x86_64,i686}: internal-error
> Fedora {21,21} x86_64 -m32: PASS
> 
> But it depends on something suspicious, for a given build the testsuite
> results are stable but for builds done at different time / under different
> configurations the results differ.

Do you know what configuration exactly caused this?

> 
> 
> Could you first check-in the gdb.fortran/dynamic-other-frame.exp testcase to
> the Intel branch?  I find it difficult to catch a crash of a testcase not even
> present in your repository.
> 

I've pushed the dynamic-other-frame test to our Github repository.
Could you please try to compile and run the tests on a clean FC20 32bit machine?

> 
> Thanks,
> Jan
> 

Thanks,
Keven


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