This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]
- From: Keven Boell <keven dot boell at linux dot intel dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Keven Boell <keven dot boell at intel dot com>, gdb-patches at sourceware dot org, sanimir dot agovic at intel dot com
- Date: Thu, 21 Aug 2014 09:27:21 +0200
- Subject: Re: [patch 1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]
- Authentication-results: sourceware.org; auth=none
- References: <1405070495-6948-1-git-send-email-keven dot boell at intel dot com> <20140729183023 dot GA17443 at host2 dot jankratochvil dot net> <20140729202710 dot GA20874 at host2 dot jankratochvil dot net> <53DB3FB3 dot 6050601 at linux dot intel dot com> <20140801210217 dot GA26015 at host2 dot jankratochvil dot net> <53E9BA7B dot 1080202 at linux dot intel dot com> <20140812215532 dot GA21463 at host2 dot jankratochvil dot net> <20140814200252 dot GA5856 at host2 dot jankratochvil dot net> <53F4ABBE dot 8030408 at linux dot intel dot com> <20140820182413 dot GA27539 at host2 dot jankratochvil dot net>
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