Hi Ulf,
sounds good.
Ragarding VS2005. I know that problem from other projects.
* time_t is 64 bit now: Use the define _USE_32BIT_TIME_T to make it
backward compatible
* wchar_t is a built-in type now. This may also cause problems,
because it was a "unsigned short" before. But you can switch this
off too with a compiler switch.
* Use _CRT_SECURE_NO_DEPRECATE to avoid anoying warnings about ANSI
C functions
regards,
Gerhard.
Ulf Lamping schrieb:
> Gerhard Gappmeier wrote:
>
>> Nevertheless I attached an update where I fixed the missing { 0, NULL
>> }entries
>> in the value_string arrays.
>>
> Good, that had to be fixed anyway.
>
>> I also attached the result of tshark so you can compare it with yours.
>> Is the access violation catched in any way and produces only a log entry,
>> or should I see an "Access Violation" message box?
>> I could not find any access violation entry in the file,
>> nor do I get a messagebox. It seems to just work for me.
>>
> I found the reason for the problem:
>
> This is not a bug in your code, but a problem which seems to be newly
> introduced in MSVC2005 (compared to MSVC6) with the changes to localtime
> (localtime64 was introduced).
>
> Calling localtime with a fairly huge value 218939827321, causes it to
> crash (to my feeling, localtime should accept all values in the possible
> range). This is triggered in to_str.c function *abs_time_to_str()*,
> around line 482, caused by a field named "PublishTime" - as I don't have
> the context, I don't know where the exact opcua code is that triggered
> this - but it doesn't really matter.
>
> However, this is a problem in the call to localtime and not in your
> code. As a first try, I'd put a simple "if(abs_time->secs > 2000000000)"
> in the code, so the problematic localtime call is not triggered when the
> value is too large (but that's probably an ugly hack). After this, the
> fuzz tests on your code runs smoothly now (at least so far ;-).
>
> I'll take a deeper look at your code if I've fixed the current problem ...
>
>> In the GUI it also works, just shows malformed packets which is normal
>> when you modify the capture file with garbage.
>>
> Yes.
>
> The slowness I've noticed was caused by slow network name resolution.
> This should be catched by ADNS (which is existing and enabled), but
> seems to currently work not. I don't know the real cause (maybe MSVC2005
> DLL problems?), but switching off network name resolution works for now
> (one problem at a time).
>
> Regards, ULFL
>
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
