[1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]
Commit Message
On Fri, 01 Aug 2014 09:20:19 +0200, Keven Boell wrote:
> I just tried it on Fedora 20 i686. Applied the patch, you mentioned, on top of
> the Fortran VLA series and executed your dynamic-other-frame test. Everything
> is working fine here, I cannot reproduce the crash.
I have it reproducible on Fedora 20 i686 with plain
CFLAGS=-g ./configure;make;cd gdb/testsuite;make site.exp;runtest gdb.fortran/dynamic-other-frame.exp
Besides that I have updated the testcase with
gdb_test_no_output "set print frame-arguments all"
so that there is no longer needed the patch:
[patch] Display Fortran strings in backtraces
https://sourceware.org/ml/gdb-patches/2014-07/msg00709.html
The fix below has no regressions for me. Unfortunately I do not see why you
cannot reproduce it.
Thanks,
Jan
Comments
On 01.08.2014 23:02, Jan Kratochvil wrote:
> On Fri, 01 Aug 2014 09:20:19 +0200, Keven Boell wrote:
>> I just tried it on Fedora 20 i686. Applied the patch, you mentioned, on top of
>> the Fortran VLA series and executed your dynamic-other-frame test. Everything
>> is working fine here, I cannot reproduce the crash.
>
> I have it reproducible on Fedora 20 i686 with plain
> CFLAGS=-g ./configure;make;cd gdb/testsuite;make site.exp;runtest gdb.fortran/dynamic-other-frame.exp
>
> Besides that I have updated the testcase with
> gdb_test_no_output "set print frame-arguments all"
> so that there is no longer needed the patch:
> [patch] Display Fortran strings in backtraces
> https://sourceware.org/ml/gdb-patches/2014-07/msg00709.html
>
> The fix below has no regressions for me. Unfortunately I do not see why you
> cannot reproduce it.
>
I installed gcc 4.9 on my FC20 32bit system and tried to reproduce the issue like
you mentioned above. Also this command sequence doesn't give me a crash. However
I added the patch, which fixes the issue on your end, you mentioned in a different mail
on the patch series and ran a make check with and without the patch. No regressions
detected on my system. I've pushed the new series to Github:
https://github.com/intel-gdb/vla/tree/vla-fortran
Could you please give it a try?
>
> Thanks,
> Jan
>
Thanks,
Keven
On Tue, 12 Aug 2014 08:55:55 +0200, Keven Boell wrote:
> On 01.08.2014 23:02, Jan Kratochvil wrote:
> > I have it reproducible on Fedora 20 i686 with plain
> > CFLAGS=-g ./configure;make;cd gdb/testsuite;make site.exp;runtest gdb.fortran/dynamic-other-frame.exp
> >
> > Besides that I have updated the testcase with
> > gdb_test_no_output "set print frame-arguments all"
> > so that there is no longer needed the patch:
> > [patch] Display Fortran strings in backtraces
> > https://sourceware.org/ml/gdb-patches/2014-07/msg00709.html
> >
> > The fix below has no regressions for me. Unfortunately I do not see why you
> > cannot reproduce it.
>
> I installed gcc 4.9 on my FC20 32bit system
This is unrelated to gcc 4.9. The problem occurs with standard Fedora 20 i686
compiler which is currently gcc-4.8.3-1.fc20.i686.
I have tried this evening to really reproduce it in 32-bit VM but it does not
happen there, despite all the involved packages are exactly the same build.
IMO it has to depend also on my x86_64 kernel where I run the i686 host in
mock chroot - but I did not try to reproduce it cleanly now.
Providing at least 32-bit build of GDB and its core:
http://people.redhat.com/jkratoch/gdb-bt.tar.xz
It is from the latest Intel vla.git clean commit:
364a416f43095996835d635561e22edceb53d380
> and tried to reproduce the issue like
> you mentioned above. Also this command sequence doesn't give me a crash. However
> I added the patch, which fixes the issue on your end, you mentioned in a different mail
> on the patch series and ran a make check with and without the patch. No regressions
> detected on my system. I've pushed the new series to Github:
> https://github.com/intel-gdb/vla/tree/vla-fortran
The difference of this new branch is only in:
https://github.com/intel-gdb/vla/commit/364a416f43095996835d635561e22edceb53d380
This is a part of:
[patch 2/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]
https://sourceware.org/ml/gdb-patches/2014-08/msg00026.html
but that patch did not fix the bug, it was only trying to add some sanity
checking (which did not work, though).
The fix of the F20 i686 bug was this patch:
[patch 1/2] Re: Crash regression(?) printing Fortran strings in bt [Re: [V2 00/23] Fortran dynamic array support]
https://sourceware.org/ml/gdb-patches/2014-08/msg00025.html
No part of that patch is in the github branch, even not the testcase.
I have verified If I apply the testcase from [patch 1/2] (=the latter one)
GDB still crashes - that is the core file gdb-bt.tar.xz above.
Thanks,
Jan
On Tue, 12 Aug 2014 23:55:32 +0200, Jan Kratochvil wrote:
> Providing at least 32-bit build of GDB and its core:
> http://people.redhat.com/jkratoch/gdb-bt.tar.xz
> It is from the latest Intel vla.git clean commit:
> 364a416f43095996835d635561e22edceb53d380
With the assertions added on the GIT branch it crashes even on F-20 x86_64
(used -fsanitize=address) so I hope it is reproducible now also for you.
Please confirm reproducibility / unreproducibility.
Thanks,
Jan
On 14.08.2014 22:02, Jan Kratochvil wrote:
> On Tue, 12 Aug 2014 23:55:32 +0200, Jan Kratochvil wrote:
>> Providing at least 32-bit build of GDB and its core:
>> http://people.redhat.com/jkratoch/gdb-bt.tar.xz
>> It is from the latest Intel vla.git clean commit:
>> 364a416f43095996835d635561e22edceb53d380
>
> With the assertions added on the GIT branch it crashes even on F-20 x86_64
> (used -fsanitize=address) so I hope it is reproducible now also for you.
> Please confirm reproducibility / unreproducibility.
>
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.
>
> Thanks,
> Jan
>
Keven
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).
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.
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.
Thanks,
Jan
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
On Thu, 21 Aug 2014 09:27:21 +0200, Keven Boell wrote:
> Since it seems that your environment differs from a clean FC20, it is hard for me to
> reproduce and debug the issues you observe.
I understand this is a problem as I was not able to reproduce it in a clean VM
myself.
But thanks for the information you are still unable to reproduce it, I was not
sure. I will look more what it cause, I have to debug the problem myself now.
> 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?
# repoquery -q --whatprovides libbabeltrace.so.1
libbabeltrace-0:1.2.1-1.fc20.i686
# yum install libbabeltrace.so.1
> > 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?
I have built it yesterday with my script "errs12 --noasan" (not providing the
script as it may be misleading) but I was building it with internal-error even
with plain 'CFLAGS=-g ./configure; make' for past mail bugreports.
> 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?
When I run it on FC20 32bit VM it really does not crash.
It crashes for me in:
mock -r fedora-20-x86_64 --init
mock -r fedora-20-x86_64 --shell
yum install ...
# even x86_64->i686
but it is all a bit customized so that clean mock may also not reproduce it.
I find it enough that you confirm you still have it unreproducible, I was not
sure. I will reply more later.
Thanks,
Jan
@@ -1659,6 +1659,7 @@ is_dynamic_type_internal (struct type *type, int top_level)
return !has_static_range (TYPE_RANGE_DATA (type));
case TYPE_CODE_ARRAY:
+ case TYPE_CODE_STRING:
{
gdb_assert (TYPE_NFIELDS (type) == 1);
new file mode 100644
@@ -0,0 +1,24 @@
+! Copyright 2010 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 2 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program; if not, write to the Free Software
+! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+!
+! Ihis file is the Fortran source file for dynamic.exp.
+! Original file written by Jakub Jelinek <jakub@redhat.com>.
+! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+subroutine bar
+ real :: dummy
+ dummy = 1
+end subroutine bar
new file mode 100644
@@ -0,0 +1,39 @@
+# Copyright 2010 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+set testfile "dynamic-other-frame"
+set srcfile1 ${testfile}.f90
+set srcfile2 ${testfile}-stub.f90
+set objfile2 [standard_output_file ${testfile}-stub.o]
+set executable ${testfile}
+set binfile [standard_output_file ${executable}]
+
+if { [gdb_compile "${srcdir}/${subdir}/${srcfile2}" "${objfile2}" object {f90}] != ""
+ || [gdb_compile "${srcdir}/${subdir}/${srcfile1} ${objfile2}" "${binfile}" executable {debug f90}] != "" } {
+ untested "Couldn't compile ${srcfile1} or ${srcfile2}"
+ return -1
+}
+
+clean_restart ${executable}
+
+gdb_test_no_output "set print frame-arguments all"
+
+if ![runto bar_] then {
+ perror "couldn't run to bar_"
+ continue
+}
+
+gdb_test "bt" {foo \(string='hello'.*}
new file mode 100644
@@ -0,0 +1,36 @@
+! Copyright 2010 Free Software Foundation, Inc.
+!
+! This program is free software; you can redistribute it and/or modify
+! it under the terms of the GNU General Public License as published by
+! the Free Software Foundation; either version 2 of the License, or
+! (at your option) any later version.
+!
+! This program is distributed in the hope that it will be useful,
+! but WITHOUT ANY WARRANTY; without even the implied warranty of
+! MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+! GNU General Public License for more details.
+!
+! You should have received a copy of the GNU General Public License
+! along with this program; if not, write to the Free Software
+! Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+!
+! Ihis file is the Fortran source file for dynamic.exp.
+! Original file written by Jakub Jelinek <jakub@redhat.com>.
+! Modified for the GDB testcase by Jan Kratochvil <jan.kratochvil@redhat.com>.
+
+subroutine foo (string)
+ interface
+ subroutine bar
+ end subroutine
+ end interface
+ character string*(*)
+ call bar ! stop-here
+end subroutine foo
+program test
+ interface
+ subroutine foo (string)
+ character string*(*)
+ end subroutine
+ end interface
+ call foo ('hello')
+end