On Sun, 2006-02-26 at 12:32 -0500, Phil Longstaff wrote:
> There were a few oddities. I originally had about 20 transactions with the
> same date. When I modified the first one, the transactions were reordered so
> that the one I was modifying was shifted down to just before the blank
> transa
On February 21, 2006 03:16 pm, Josh Sled wrote:
> On Sun, 2006-02-19 at 12:21 -0500, Phil Longstaff wrote:
> > 2) After g2 is up, I open an account, switch to ledger view, put my
> > cursor into a split and start pressing delete-tab-delete-tab... I then
> > get the listing shown in attachment gnuc
On Sun, 2006-02-19 at 12:21 -0500, Phil Longstaff wrote:
> 2) After g2 is up, I open an account, switch to ledger view, put my cursor
> into a split and start pressing delete-tab-delete-tab... I then get the
> listing shown in attachment gnucash.valgrind. I added printf statements to
> show as
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
On February 19, 2006 08:41 pm, Derek Atkins wrote:
I still can't believe that there's no way to tell valgrind
"this memory object is initialized, even if it may be 'tained'
by uninitialized memory".. That would seem to be a core
suppression method,
On February 19, 2006 08:41 pm, Derek Atkins wrote:
> I still can't believe that there's no way to tell valgrind
> "this memory object is initialized, even if it may be 'tained'
> by uninitialized memory".. That would seem to be a core
> suppression method, the "I know this data object is clean".
Chris Shoemaker <[EMAIL PROTECTED]> writes:
> Been there, done that. The problem with using valgrind suppressions
> for this is that you'd need a supression for every codepath that jumps
> on a guid read, like every instance of a ghashtable that uses guid
> keys and every place we store a guid an
On Sun, Feb 19, 2006 at 02:01:08PM -0500, Phil Longstaff wrote:
> On February 19, 2006 06:43 pm, Derek Atkins wrote:
> > Phil Longstaff <[EMAIL PROTECTED]> writes:
> > > The attached patch replaces the const 16 with GUID_DATA_SIZE, only
> > > compares the guid data, not the other field in the struc
On February 19, 2006 06:43 pm, Derek Atkins wrote:
> Phil Longstaff <[EMAIL PROTECTED]> writes:
> > The attached patch replaces the const 16 with GUID_DATA_SIZE, only
> > compares the guid data, not the other field in the struct, and removes
> > the use of the dirent structure in md5 calculation.
>
On February 19, 2006 06:09 pm, Josh Sled wrote:
> On Sun, 2006-02-19 at 17:57 -0500, Derek Atkins wrote:
> > > 2) After g2 is up, I open an account, switch to ledger view, put my
> > > cursor into a split and start pressing delete-tab-delete-tab... I then
> > > get the listing shown in attachment
Phil Longstaff <[EMAIL PROTECTED]> writes:
> The attached patch replaces the const 16 with GUID_DATA_SIZE, only compares
> the guid data, not the other field in the struct, and removes the use of the
> dirent structure in md5 calculation.
I've applied everything but the part to remove the diren
On Sun, 2006-02-19 at 17:57 -0500, Derek Atkins wrote:
> > 2) After g2 is up, I open an account, switch to ledger view, put my cursor
> > into a split and start pressing delete-tab-delete-tab... I then get the
> > listing shown in attachment gnucash.valgrind. I added printf statements to
> > show
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
I've been playing around with G2 and valgrind 3.1.0 and have seen the
following issues on SuSE 9.3:
1) There are lots of messages about decisions based on uninitialized
variables
and accessing past the end of malloc'ed mem in the c
12 matches
Mail list logo
