* Re: Correction of a crash in sim_memory_uninstall [not found] <37066006.ACFDED96.cygnus.patches.gdb@worldnet.fr> @ 1999-04-14 12:46 ` Frank Ch. Eigler 1999-04-14 13:22 ` Frank Ch. Eigler 0 siblings, 1 reply; 4+ messages in thread From: Frank Ch. Eigler @ 1999-04-14 12:46 UTC (permalink / raw) To: Stephane Carrez; +Cc: gdb-patches stcarrez@worldnet.fr (Stephane Carrez) writes: > I've found a problem in the common part of the simulator. It > crashes in `sim_memory_uninstall' when the simulator terminates. > [...] Thanks for finding this problem. Your patch looks fine. - FChE ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Correction of a crash in sim_memory_uninstall 1999-04-14 12:46 ` Correction of a crash in sim_memory_uninstall Frank Ch. Eigler @ 1999-04-14 13:22 ` Frank Ch. Eigler 0 siblings, 0 replies; 4+ messages in thread From: Frank Ch. Eigler @ 1999-04-14 13:22 UTC (permalink / raw) To: Stephane Carrez; +Cc: gdb-patches stcarrez@worldnet.fr (Stephane Carrez) writes: > I've found a problem in the common part of the simulator. It > crashes in `sim_memory_uninstall' when the simulator terminates. > [...] Thanks for finding this problem. Your patch looks fine. - FChE From jimb@cygnus.com Thu Apr 15 11:41:00 1999 From: Jim Blandy <jimb@cygnus.com> To: Manfred Hollstein <manfred.h@gmx.net> Cc: bug-gdb@gnu.org, gdb-patches@cygnus.com Subject: Re: PATCH: fix unitialized memory reads in bfd/elf32-mips.c Date: Thu, 15 Apr 1999 11:41:00 -0000 Message-id: <npiuaxyf3t.fsf@zwingli.cygnus.com> References: <14034.52083.787129.934623@exept.exept.de> <14100.46517.331398.118164@saturn.hollstein.net> X-SW-Source: 1999-04/msg00033.html Content-length: 2716 > I reported this problem already with bfd in binutils-2.9.1 and gdb-4.17; > as it is still present in gdb-4.18, I'm re-posting a patch. An equivalent patch has been applied now. Thanks! ------- Start of forwarded message ------- Message-ID: <19990414143605.B28302@cygnus.com> Date: Wed, 14 Apr 1999 14:36:05 -0700 From: Richard Henderson <rth@cygnus.com> To: Jim Blandy <jimb@cygnus.com> Subject: Re: [manfred-h@t-online.de (Manfred Hollstein)] PATCH: fix unitialized memory reads in bfd/elf32-mips.c References: <npbtgryt9k.fsf@zwingli.cygnus.com> On Wed, Apr 14, 1999 at 01:03:03PM -0500, Jim Blandy wrote: > 1999-04-14 Manfred Hollstein <mhollstein@cygnus.com> > > * elf32-mips.c (_bfd_mips_elf_read_ecoff_info): Set all > fields to 0 which may cause erroneous calls to free when > "goto error_return" is executed. > > + debug->line = 0; > + debug->external_dnr = 0; > + debug->external_pdr = 0; > + debug->external_sym = 0; > + debug->external_opt = 0; > + debug->external_aux = 0; > + debug->ss = 0; > + debug->ssext = 0; > + debug->external_fdr = 0; > + debug->external_rfd = 0; > + debug->external_ext = 0; I've committed the following instead. Thanks. r~ Wed Apr 14 14:33:08 1999 Richard Henderson <rth@cygnus.com> * elf32-mips.c (_bfd_mips_elf_read_ecoff_info): Zero `debug'. * elf64-alpha.c (elf64_alpha_read_ecoff_info): Likewise. Index: elf32-mips.c =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v retrieving revision 1.153 diff -c -p -d -r1.153 elf32-mips.c *** elf32-mips.c 1999/04/10 23:24:04 1.153 --- elf32-mips.c 1999/04/14 21:32:49 *************** _bfd_mips_elf_read_ecoff_info (abfd, sec *** 3330,3335 **** --- 3330,3336 ---- char *ext_hdr = NULL; swap = get_elf_backend_data (abfd)->elf_backend_ecoff_debug_swap; + memset (debug, 0, sizeof(*debug)); ext_hdr = (char *) bfd_malloc ((size_t) swap->external_hdr_size); if (ext_hdr == NULL && swap->external_hdr_size != 0) Index: elf64-alpha.c =================================================================== RCS file: /cvs/cvsfiles/devo/bfd/elf64-alpha.c,v retrieving revision 1.43 diff -c -p -d -r1.43 elf64-alpha.c *** elf64-alpha.c 1999/04/10 23:24:04 1.43 --- elf64-alpha.c 1999/04/14 21:32:49 *************** elf64_alpha_read_ecoff_info (abfd, secti *** 1950,1955 **** --- 1950,1956 ---- char *ext_hdr = NULL; swap = get_elf_backend_data (abfd)->elf_backend_ecoff_debug_swap; + memset (debug, 0, sizeof(*debug)); ext_hdr = (char *) bfd_malloc ((size_t) swap->external_hdr_size); if (ext_hdr == NULL && swap->external_hdr_size != 0) ------- End of forwarded message ------- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Correction of a crash in sim_memory_uninstall
@ 1999-04-03 11:37 Stephane Carrez
1999-04-03 12:27 ` Stephane Carrez
0 siblings, 1 reply; 4+ messages in thread
From: Stephane Carrez @ 1999-04-03 11:37 UTC (permalink / raw)
To: gdb-patches
Hi!
I've found a problem in the common part of the simulator.
It crashes in `sim_memory_uninstall' when the simulator terminates.
The problem is when this operation walks a list and frees the
sim_memopt objects. It frees the entry (line 457, call to zfree)
and then gets the pointer to the next one, accessing the freed data
(line 461, *entry = (*entry)->next).
One fix consist in updating 'entry' before the while loop.
Hope this helps,
Stephane
*** /src/gnu/gdb-19990330/sim/common/sim-memopt.c Thu Jan 28 15:13:33
1999
--- sim-memopt.c Sat Apr 3 20:06:42 1999
***************
*** 449,454 ****
--- 449,457 ----
/* delete it and its aliases */
alias = *entry;
+
+ /* next victim */
+ *entry = (*entry)->next;
while (alias != NULL)
{
sim_memopt *dead = alias;
***************
*** 456,464 ****
sim_core_detach (sd, NULL, dead->level, dead->space, dead->addr);
zfree (dead);
}
-
- /* next victim */
- *entry = (*entry)->next;
}
}
--- 459,464 ----
^ permalink raw reply [flat|nested] 4+ messages in thread* Correction of a crash in sim_memory_uninstall 1999-04-03 11:37 Stephane Carrez @ 1999-04-03 12:27 ` Stephane Carrez 0 siblings, 0 replies; 4+ messages in thread From: Stephane Carrez @ 1999-04-03 12:27 UTC (permalink / raw) To: gdb-patches Hi! I've found a problem in the common part of the simulator. It crashes in `sim_memory_uninstall' when the simulator terminates. The problem is when this operation walks a list and frees the sim_memopt objects. It frees the entry (line 457, call to zfree) and then gets the pointer to the next one, accessing the freed data (line 461, *entry = (*entry)->next). One fix consist in updating 'entry' before the while loop. Hope this helps, Stephane *** /src/gnu/gdb-19990330/sim/common/sim-memopt.c Thu Jan 28 15:13:33 1999 --- sim-memopt.c Sat Apr 3 20:06:42 1999 *************** *** 449,454 **** --- 449,457 ---- /* delete it and its aliases */ alias = *entry; + + /* next victim */ + *entry = (*entry)->next; while (alias != NULL) { sim_memopt *dead = alias; *************** *** 456,464 **** sim_core_detach (sd, NULL, dead->level, dead->space, dead->addr); zfree (dead); } - - /* next victim */ - *entry = (*entry)->next; } } --- 459,464 ---- From phdm@macqel.be Wed Apr 07 10:43:00 1999 From: "Philippe De Muyter" <phdm@macqel.be> To: gdb-patches@cygnus.com (gdb-patches@cygnus.com) Subject: testsuite/print_long_arg_list Date: Wed, 07 Apr 1999 10:43:00 -0000 Message-id: <199904071649.SAA28333@mail.macqel.be> X-SW-Source: 1999-04/msg00001.html Content-length: 2437 Running the testsuite with gdb-4.17.87 on m68k-motorola-sysv, I got (among others) the following failure : print_long_arg_list (a=22.219999999999998, b=33.332999999999998, c=0, d=-25, e=1 00, f=2345, struct1={value = 6, head = 0}, struct2={value = 10, head = 0}, struc t3={value = 12, head = 0}, struct4={value = 14, head = 0}, flags={alpha = 1, bet a = 0, gamma = 1, delta = 0, epsilon = 1, omega = 0}, flags_combo={alpha = 1, be ta = 0, ch1 = 121 'y', gamma = 1, delta = 0, ch2 = 110 'n', epsilon = 1, omega = 0}, three_char={ch1 = 97 'a', ch2 = 98 'b', ch3 = 99 'c'}, five_char={ch1 = 108 'l', ch2 = 109 'm', ch3 = 110 'n', ch4 = 111 'o', ch5 = 112 'p'}, int_char_comb o={int1 = 123, ch1 = 122 'z'}, d1={double1 = 10.5}, d2={double1 = -3.33999999999 99998}, d3={double1 = 675.09122999999999}, f1={float1 = 45.2340012, float2 = 43. 5999985}, f2={float1 = 78.0100021, float2 = 122.099998}, f3={float1 = -1232.3449 7, float2 = -199.210007}) at call-ar-st.c:813 813 printf("double : %f\n", a); (gdb) FAIL: gdb.base/call-ar-st.exp: step into print_long_arg_list Looking at the expected result, I see : gdb_expect { -re ".*print_long_arg_list \\(a=22.219999999999999, b=33.332999999999998 , c=0, d=-25, e=100, f=2345, struct1=\{value = 6, head = 0\}, struct2=\{value = 10, head = 0\}, struct3=\{value = 12, head = 0\}, struct4=\{value = 14, head = 0 \}, flags=\{alpha = 1, beta = 0, gamma = 1, delta = 0, epsilon = 1, omega = 0\}, flags_combo=\{alpha = 1, beta = 0, ch1 = 121 \'y\', gamma = 1, delta = 0, ch2 = 110 \'n\', epsilon = 1, omega = 0\}, three_char=\{ch1 = 97 \'a\', ch2 = 98 \'b\ ', ch3 = 99 \'c\'\}, five_char=\{ch1 = 108 \'l\', ch2 = 109 \'m\', ch3 = 110 \'n \', ch4 = 111 \'o\', ch5 = 112 \'p\'\}, int_char_combo=\{int1 = 123, ch1 = 122 \ 'z\'\}, d1=\{double1 = 10.5\}, d2=\{double1 = -3.3399999999999999\}, d3=\{double 1 = 675.09123\}, f1=\{float1 = 45.2340012, float2 = 43.5999985\}, f2=\{float1 = 78.0100021, float2 = 122.099998\}, f3=\{float1 = -1232.34497, float2 = -199.2100 07\}\\) at ${srcdir}/${subdir}/${srcfile}:813\[\r\n\]+813\[ \t\]+printf\\(\"doub le :.*\", a\\);.*$gdb_prompt $" {pass "step into print_long_arg_list"} -re ".*$gdb_prompt $" { fail "step into print_long_arg_list" } timeout { fail "step into print_long_arg_list (timeout)" } } For me, the differences are in the last digits of some float or double numbers. Isn't the test too strict ? Philippe ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-04-14 13:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <37066006.ACFDED96.cygnus.patches.gdb@worldnet.fr>
1999-04-14 12:46 ` Correction of a crash in sim_memory_uninstall Frank Ch. Eigler
1999-04-14 13:22 ` Frank Ch. Eigler
1999-04-03 11:37 Stephane Carrez
1999-04-03 12:27 ` Stephane Carrez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox