It should be a temporary file, try adding -k to A2W_FLAGS in
makefile.common:
A2W_FLAGS= -b -k
Regards
Anders
Maynard, Chris skrev 2013-12-13 23:19:
Hmm, I'm on Windows 7 x64 using nmake and it never gets generated. I must be
missing something, but I'm out of time for today.
-Original M
Ed Beroset wrote:
Evan Huus wrote:
The part that's confusing me is that somehow
actx->external.direct_reference seems to be getting a pointer to this
stale ep-allocated buffer, but I can't find anywhere in the call stack
that value could be set to such a stale buffer.
That would probably be d
Evan Huus wrote:
The part that's confusing me is that somehow
actx->external.direct_reference seems to be getting a pointer to this
stale ep-allocated buffer, but I can't find anywhere in the call stack
that value could be set to such a stale buffer.
That would probably be dissect_ber_OBJECT_I
On Sun, Dec 15, 2013 at 12:33 PM, Ed Beroset wrote:
> Evan Huus wrote:
>
>> In one sense the problem is easy to trace: the oid resolution code is
>> returning the resolved string in an ep-allocated buffer, which is then
>> getting freed and subsequently used. However, I'm having trouble
>> trackin
Evan Huus wrote:
In one sense the problem is easy to trace: the oid resolution code is
returning the resolved string in an ep-allocated buffer, which is then
getting freed and subsequently used. However, I'm having trouble
tracking down exactly where this resolved oid is being persisted
between
I was running some valgrind fuzzing and I got a file that produces the
following valgrind trace:
==8013== Invalid read of size 1
==8013==at 0x95F89D0: g_str_hash (ghash.c:1732)
==8013==by 0x95F8058: g_hash_table_lookup (ghash.c:365)
==8013==by 0x65DE56E: call_ber_oid_callback (packet-b
