No subject

First chance exception: page fault on read access to 0x00000000 in 32-bit code
(0x6034fa0d).

The debugger shows which variables are being addressed:

356             if (oid1->ids[i] > oid2->ids[i]) return 1;

That is, one of oid1, oid2, oid1->ids, or oid2->ids is NULL.  Looking at the
call stack, we can rule out the first two possibilities:

=>0 0x6034fa0d SnmpUtilOidNCmp+0x5d(oid1=0x33fba4, oid2=0x33fbec, count=10)
[/home/cahrendt/wine-git/dlls/snmpapi/main.c:356] in snmpapi (0x0033faa8)
  1 0x60339eb5 testQuery+0x13d5()

That is, oid1 and oid2 aren't NULL.  So oid1->ids is NULL or oid2->ids is NULL.
 Looking at SnmpUtilOidNCmp some more, they will only be dereferenced if
oids1->idLength is positive, oid2->idLength is positive, and count is positive:

    len = min(count, oid1->idLength);
    len = min(len, oid2->idLength);
    for (i = 0; i < len; i++)
    {
        if (oid1->ids[i] > oid2->ids[i]) return 1;

We already know count is 10, from the backtrace.  So both oid1->idLength and
oid2->idLength are positive, but one of oid1->ids or oid2->ids is NULL.  This
is certainly possible, if a memory allocation in SnmpUtilOidAppend fails:  it
will return a failure code, but not reset idLength to 0 if memory allocation
fails.

Without being able to reproduce it here, it's hard to know what's going on. 
Improving the traces to snmpapi might yield a clue.  For example, rather than
tracing the pointer arguments to SnmpUtilOidAppend, the values (ids and
idLength) of the pointers might be traced instead.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.