[Bug 17996] inetmib1 test page faults

http://bugs.winehq.org/show_bug.cgi?id=17996

--- Comment #30 from Juan Lang   2009-04-13 11:01:35 ---
> From the look of it, one of the oids (vars or vars2) has become corrupt.

There's a NULL-pointer violation:

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.