lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] product editor feedback


From: Greg Chicares
Subject: Re: [lmi] product editor feedback
Date: Fri, 02 Mar 2007 03:13:34 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2007-3-2 1:59 UTC, Wendy Boutin wrote:
> Below is feedback on the product editor implementation that's in our
> cvs as of the current release tag 'lmi-20070223T1820Z'

The issue I report below arises with the unmodified
'product-editor_branch' sources, as well as being
reproducible with current HEAD.

> database
[...]
>  - occasionally encountered this problem, but more consistently with a
>     proprietary product:
> File | Open | sample.db4
[...]
> [...] Error [...]
> Trying to index database item with key 66677016 past end of data.
> [file c:/opt/lmi/src/lmi/ihs_dbvalue.cpp, line 337]

I get a reproducible crash when I load 'sample.db4' from the
file-history menu. I copied and pasted a report below from
the 'drmingw' just-in-time debugger [1]. It reports
  "Access Violation...Reading from location 00000001"
on this line
  return m_table->GetValue( row, col );
in wxGrid::GetCellValue(int, int).

You observe an unexpectedly-large key, 66677016, which is
trapped; I get a dereference of address 0x01, which is not.
That particular address varies from one run to another.

By loading another file first, then loading a database file,
I can get different outcomes: sometimes everything seems to
work, while other times I observe messages like this:

  Assertion 'a_idx[j] < axis_lengths[j]' failed.
  [file C:/lmi/checkouts/product-editor_branch/lmi/ihs_dbvalue.cpp, line 324]

(after which I needed to terminate the program manually), or:

  Trying to index database item with key 0 past end of data.
  [file C:/lmi/checkouts/product-editor_branch/lmi/ihs_dbvalue.cpp, line 337]

(after which it abended in a way that 'drmingw' didn't catch).
But each time 'drmingw' traps it, the segfault is always on
the same line. My machine, my OS, and, probably more important,
my product files are different from yours; but the product-file
differences arise only because mine are generated from older
(proprietary) code that was in production a few months ago, and
in other respects the system works fine.

My hypothesis is that DatabaseTableAdapter::db_value_ is getting
corrupted in some way that (when it crashes) eludes the sanity
tests in TDBValue::operator[](). I wouldn't claim that those
tests are comprehensive.

---------

'drmingw' report:

lmi_wx_shared.exe caused an Access Violation at location 00417f2b in module 
lmi_wx_shared.EXE Reading from location 00000001.

Registers:
eax=00000001 ebx=03191078 ecx=031976cc edx=00000001 esi=03191088 edi=0022efa4
eip=00417f2b esp=0022ef04 ebp=0022ef3c iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000216

Call stack:
AddrPC     AddrReturn AddrFrame  AddrStack  Params
00417F2B   0042FFD5   0022EF3C   0022EF04   0022EFA4   03191078   031905F8   
0022EF94
00417F2B  lmi_wx_shared.EXE:00417F2B  _onexit  crt1.c:278
_onexit_t _onexit(
        _onexit_t pfn = &C:\opt\lmi\bin\lmi_wx_shared.EXE: No symbol found
0x0022efa4
)
0042FFD5   105162FD   0022EFCC   0022EF04   0022F054   03190408   00000000   
00000000
0042FFD5  lmi_wx_shared.EXE:0042FFD5  _onexit  crt1.c:278
_onexit_t _onexit(
        _onexit_t pfn = &C:\opt\lmi\bin\lmi_wx_shared.EXE: No symbol found
0x0022f054
)
105162FD   1029318B   0022EFEC   0022EF04   0022F054   031AA2A8   00000000   
00000000
105162FD  wxmsw28_gcc_344.dll:105162FD  _ZN6wxGrid12GetCellValueEii  grid.h:1483
        ...
                if ( m_table )
                {
>                   return m_table->GetValue( row, col );
                }
                else
        ...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]