From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 Description of problem: Running gdb under FC3 fails when doing inferior function calls. This involves gdb calling a known function in the application and evaluating the result. A SIGTRAP is being found by gdb at the entry point of the function the 2nd time we call the same function. Gdb is not setting this breakpoint and when it trips over the trap it is forced to issue a message and stop evaluation of the result. This same test and version of gdb runs fine under RHEL3 and RHEL4. The test also works fine under FC4 on ia64. Version-Release number of selected component (if applicable): kernel-2.6.10-1.760_FC3smp How reproducible: Always Steps to Reproduce: 1.gcc -g callfuncs.c 2.gdb -nw callfuncs 3.b main 4.run 5.next 6.next 7.next 8.p t_char_values ('a', 'b') 9.p t_char_values ('a', 'b') <== this gets an extraneous trap Actual Results: (gdb) b main Breakpoint 1 at 0x8048987: file ../../../gdb-6.3/gdb/testsuite/gdb.base/callfuncs.c, line 389. (gdb) run Starting program: /usr/src/redhat/BUILD/gdb-6.3.0.0-build-i386-redhat-linux-gnu/gdb/testsuite/gdb.base/callfuncs Breakpoint 1, main () at ../../../gdb-6.3/gdb/testsuite/gdb.base/callfuncs.c:389 389 malloc(1); (gdb) next 390 t_double_values(double_val1, double_val2); (gdb) 391 t_structs_c(struct_val1); (gdb) 392 return 0 ; (gdb) p t_char_values ('a', 'b') $1 = 1 (gdb) p t_char_values ('a', 'b') Program received signal SIGTRAP, Trace/breakpoint trap. 0x0804854f in t_char_values (char_arg1=-65 '�', char_arg2=-4 '�') at ../../../gdb-6.3/gdb/testsuite/gdb.base/callfuncs.c:217 217 { The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (t_char_values) will be abandoned. Expected Results: The second call to p t_char_values ('a', 'b') should have succeeded and returned back the same return value as the previous attempt. Additional info:
Created attachment 111313 [details] testcase
dupe of 144805 ?
Yes. It is a duplicate. I will close it as such. *** This bug has been marked as a duplicate of 144805 ***