http://bugs.winehq.org/show_bug.cgi?id=17996 --- Comment #30 from Juan Lang <juan_lang(a)yahoo.com> 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. -- 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.