... FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: cast to array with two arguments FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: set vec1 FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: cast to vector with one argument FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: set vec2 FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: cast to vector with two arguments FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: guile (print (value=? vec1 vec2)) FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: set vec3 FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: guile (print (value=? vec1 vec3)) ...
First one in more detail: ... (gdb) PASS: gdb.guile/scm-type.exp: lang_c: test_fields: cast to array with one argument guile (print (value-cast ar0 (type-array (value-type ar0) 0 1)))^M ERROR: In procedure type-array:^M ERROR: In procedure gdbscm_type_array: Wrong type argument in position 1 (expecting gdb:type): #<finalized smob 2346790>^M Error while executing Scheme code.^M (gdb) FAIL: gdb.guile/scm-type.exp: lang_c: test_fields: cast to array with two arguments ...
Reproduced at commit 60122dbef4, in a loop: ... $ for n in $(seq 1 100); do ./test.sh 2>&1 | grep "expected passes"; done # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 129 # of expected passes 121 # of expected passes 129 ...
Reproduced at master: ... $ for n in $(seq 1 100); do echo -n "$n: "; ./test.sh 2>&1 | grep "expected passes"; done ... 36: # of expected passes 129 37: # of expected passes 121 38: # of expected passes 129 ...
Created attachment 12796 [details] patch that minimizes test-case I did a 500 iterations run, and the problem triggered 4 times...
This is with guile 2.0 .
I've tested running this in a loop (without your patch): make check TESTS=gdb.guile/scm-type.exp On x86_64-linux-gnu, I can reproduce the issue with Guile 2.0.14 after a few runs. I cannot reproduce it with Guile 3.0.4 after 20-or-so runs.
(In reply to Ludovic Courtès from comment #6) > On x86_64-linux-gnu, I can reproduce the issue with Guile 2.0.14 after a few > runs. I cannot reproduce it with Guile 3.0.4 after 20-or-so runs. The problem on 2.0 is still present after reverting 68cf161c24b096608bf4a1b97b489cc7277bffc0.
I tried running the tests under 'rr' but that seems to prevent GDB from spawning the inferior or something: FAIL: gdb.guile/scm-type.exp: can't run to main Is there a trick to achieve that?
(In reply to Ludovic Courtès from comment #8) > I tried running the tests under 'rr' Is that https://rr-project.org/ ? > but that seems to prevent GDB from > spawning the inferior or something: > > FAIL: gdb.guile/scm-type.exp: can't run to main > > Is there a trick to achieve that? Can you show how you tried this?
(In reply to Tom de Vries from comment #9) > (In reply to Ludovic Courtès from comment #8) > > I tried running the tests under 'rr' > > Is that https://rr-project.org/ ? > > > but that seems to prevent GDB from > > spawning the inferior or something: > > > > FAIL: gdb.guile/scm-type.exp: can't run to main > > > > Is there a trick to achieve that? > > Can you show how you tried this? OK, I managed, using: ... @@ -1895,6 +1895,8 @@ proc gdb_file_cmd { arg } { } } +set GDB "rr $GDB" + # Default gdb_spawn procedure. proc default_gdb_spawn { } { ... Then, I made it clear we're running into a timeout: ... @@ -689,7 +689,7 @@ proc runto { function args } { # If you don't want that, use gdb_start_cmd. proc runto_main { } { - return [runto main no-message] + return [runto main message] } ### Continue, and expect to hit a breakpoint. ... such that we get: ... FAIL: gdb.guile/scm-type.exp: running to main in runto (timeout) FAIL: gdb.guile/scm-type.exp: can't run to main ... I've then tried to increase the timeout to: ... @@ -632,7 +632,7 @@ proc runto { function args } { # the "at foo.c:36" output we get with -g. # the "in func" output we get without -g. - gdb_expect 30 { + gdb_expect 600 { -re "Break.* at .*:$decimal.*$gdb_prompt $" { if { $print_pass } { pass $test_name ... but I haven't found a value yet that works.
I ported the test-case to the command line (hopefully, that'll be easier to debug). Using this python script to ignore errors: ... $ cat ignore-errors.py class IgnoreErrorsCommand (gdb.Command): """Execute a single command, ignoring all errors. Only one-line commands are supported. This is primarily useful in scripts.""" def __init__ (self): super (IgnoreErrorsCommand, self).__init__ ("ignore-errors", gdb.COMMAND_OBSCURE, # FIXME... gdb.COMPLETE_COMMAND) def invoke (self, arg, from_tty): try: gdb.execute (arg, from_tty) except: pass IgnoreErrorsCommand () ... and this command file: ... $ cat cmd.gdb source ignore-errors.py set height 0 set width 0 dir dir /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.guile file /home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.guile/scm-type/scm-type guile (display "test\n") delete breakpoints info breakpoints break -qualified main run guile (define (print x) (format #t "= ~A" x) (newline)) guile (define (raw-print x) (format #t "= ~S" x) (newline)) guile (use-modules (gdb)) guile (use-modules (gdb iterator)) break 88 continue guile (print (length (type-fields (value-type (parse-and-eval "ts"))))) print st guile (define st (history-ref 0)) guile (define st-type (value-type st)) guile (define fields (type-fields st-type)) guile (print (length fields)) guile (print (field-name (car fields))) guile (print (field-name (cadr fields))) guile (print (field-name (type-field st-type "a"))) guile (print (type-has-field? st-type "b")) guile (print (type-has-field? st-type "nosuch")) guile (print (type-num-fields (value-type st))) guile (define fi (make-field-iterator st-type)) guile (print (iterator-map field-bitpos fi)) ignore-errors guile (print (make-field-iterator (field-type (type-field st-type "a")))) print ar guile (define ar (history-ref 0)) guile (define ar0 (value-subscript ar 0)) guile (print (value-cast ar0 (type-array (value-type ar0) 1))) guile (print (value-cast ar0 (type-array (value-type ar0) 0 1))) ... And this command line: ... $ gdb -q -batch outputs/gdb.guile/scm-type/scm-type -x cmd.gdb ... When run like so in conjunction with stress -c 5: ... $ for n in $(seq 100); do gdb -q -batch outputs/gdb.guile/scm-type/scm-type -x cmd.gdb; echo $?; done 2>&1 | tee LOG ... I get: ... $ grep wrong -i LOG ERROR: In procedure gdbscm_type_array: Wrong type argument in position 1 (expecting gdb:type): #<finalized smob 22771c0> ERROR: In procedure gdbscm_type_array: Wrong type argument in position 1 (expecting gdb:type): #<finalized smob 21db1b0> ERROR: In procedure gdbscm_type_array: Wrong type argument in position 1 (expecting gdb:type): #<finalized smob 233b1c0> ERROR: In procedure gdbscm_type_array: Wrong type argument in position 1 (expecting gdb:type): #<finalized smob 22801c0> ...
(In reply to Ludovic Courtès from comment #8) > I tried running the tests under 'rr' but that seems to prevent GDB from > spawning the inferior or something: > > FAIL: gdb.guile/scm-type.exp: can't run to main > > Is there a trick to achieve that? Perhaps you could try again with the setup described in comment 11?