[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: Number_minus problem
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: Number_minus problem |
Date: |
30 Dec 2005 18:21:59 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings! OK, I think this is now resolved from your subsequent
post. Please let me know if problems persist.
Take care,
"Mike Thomas" <address@hidden> writes:
> Hi Camm.
>
> I'm having trouble with number_minus on fixnums which calls mpz_set_si
> apparently with a bad pointer in the dest->_mp_d[0] field (line 32
> gmp3/mpz/set_si.c) corrupting memory it shouldn't be accessing
> (according to gdb).
>
> See **NOTE** below.
>
> Hoping to catch you before you go off-line for the evening.
>
> Mike Thomas
>
> ----------------------------------------------------------------
>
>
> $ gdb-5.2.1 --args ../unixport/saved_pre_gcl.exe ../unixport -system-p
> -c-file
> -data-file -o-file nil -h-file -compile gcl_arraylib
> GNU gdb 5.2.1
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "i686-pc-mingw32"...
> (gdb) b number_minus
> Breakpoint 1 at 0x4612de: file num_arith.c, line 387.
> (gdb) r
> Starting program: c:\cvs\head\gcl\lsp/../unixport/saved_pre_gcl.exe
> ../unixport
> -system-p -c-file -data-file -o-file nil -h-file -compile gcl_arraylib
>
> Breakpoint 1, number_minus (x=0xa000000a, y=0xa0000001) at
> num_arith.c:387
> 387 if ( ARGC == 10 ) {
> (gdb) n
> 388 fprintf ( stdout, "number_minus ARGV[9] %s\n", ARGV[9] );
> (gdb) n
> 390 switch (type_of(x)) {
> (gdb) n
> 393 switch(type_of(y)) {
> (gdb) n
> 395 MPOP(return,subss,fix(x),fix(y));
> (gdb) s
> m__gmpz_set_si (_b=0x3211fe4, _c=10) at ../h/../h/gmp_wrappers.h:142
> 142 MEM_GMP_CALL(2,void,mpz_set_si,1,mpz_t,long int)
> (gdb) n
> number_minus (x=0xa000000a, y=0xa0000001) at num_arith.c:524
> 524 }
> (gdb) n
> Lminus () at num_arith.c:1000
> 1000 for (i = 1; i < j; i++)
> (gdb) c
> Continuing.
>
> Breakpoint 1, number_minus (x=0xa0000009, y=0xa0000001) at
> num_arith.c:387
> 387 if ( ARGC == 10 ) {
> (gdb) delete 1
> (gdb) c
> Continuing.
> warning: HEAP[saved_pre_gcl.exe]:
> warning: HEAP: Free Heap block 812648 modified at 812df8 after it was
> freed
>
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x7c901231 in _libwsock32_a_iname ()
>
> ---------------------------------------------------------------------
>
>
> So I restart with a breakpoint at number_minus and check the location at
> 0x812df8:
>
>
>
> ---------------------------------------------------------------------
> (gdb) b number_minus
> Breakpoint 2 at 0x4612de: file num_arith.c, line 387.
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
>
> Starting program: c:\cvs\head\gcl\lsp/../unixport/saved_pre_gcl.exe
> ../unixport
> -system-p -c-file -data-file -o-file nil -h-file -compile gcl_arraylib
>
> Breakpoint 2, number_minus (x=0xa000000a, y=0xa0000001) at
> num_arith.c:387
> 387 if ( ARGC == 10 ) {
> (gdb) p *(0x812df8)
> $1 = -17891602
> (gdb) p /x *(0x812df8)
> $2 = 0xfeeefeee
> (gdb) n
> 388 fprintf ( stdout, "number_minus ARGV[9] %s\n", ARGV[9] );
> (gdb) n
> 390 switch (type_of(x)) {
> (gdb) n
> 393 switch(type_of(y)) {
> (gdb) n
> 395 MPOP(return,subss,fix(x),fix(y));
> (gdb) p /x *(0x812df8)
> $3 = 0xfeeefeee
> (gdb) s
> m__gmpz_set_si (_b=0x3211fe4, _c=10) at ../h/../h/gmp_wrappers.h:142
> 142 MEM_GMP_CALL(2,void,mpz_set_si,1,mpz_t,long int)
> (gdb) p /x *(0x812df8)
> $4 = 0xfeeefeee
> (gdb) s
> __gmpz_set_si (dest=0x461482, val=52502500) at set_si.c:27
> 27 {
> (gdb) p /x *(0x812df8)
> $5 = 0xfeeefeee
> (gdb) p /x 52502500
> $6 = 0x3211fe4
>
>
> **NOTE**
> 0x3211fe4 (aka 52502500) is in the GCL heap.
> 0x812df8 is not, and is dangerously close to where the MSVC
> malloced memory is being placed. This leads to overwrites of
> the argv (hence ARGV) data.
>
> You may wonder why the MSVC malloc is being used (a bad thing).
>
> That is because if I use GCL's malloc, it fails before main
> even starts while allocating things like the argv data.
>
>
>
> (gdb) s
> 30 if (val > 0)
> (gdb) s
> 27 {
> (gdb) s
> 30 if (val > 0)
> (gdb) s
> 32 dest->_mp_d[0] = val;
> (gdb) p *dest
> $7 = {_mp_alloc = 1, _mp_size = 1, _mp_d = 0x812df8}
> (gdb) p /x 52502500
> $8 = 0x3211fe4
> (gdb) p /x *(0x812df8)
> $9 = 0xfeeefeee
> (gdb) s
> 33 dest->_mp_size = 1;
> (gdb) p /x *(0x812df8)
> $10 = 0xa
> (gdb) p /x *((unsigned long *)0x812df8)
> $11 = 0xa
> (gdb) p /x *(0x812df7)
> $12 = 0xafe
> (gdb) p /x *(0x812df6)
> $13 = 0xafeee
> (gdb) p /x *(0x812df5)
> $14 = 0xafeeefe
> (gdb) p /x *(0x812df4)
> $15 = 0xfeeefeee
> (gdb) p /x *(0x812df9)
> $16 = 0xee000000
> (gdb) p /x *(0x812dfa)
> $17 = 0xfeee0000
> (gdb)
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah