ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 10476] Consistent crashes reading PCAP from tPacketCapture

Date: Mon, 29 Sep 2014 14:51:58 +0000

Comment # 33 on bug 10476 from
(In reply to Pascal Quantin from comment #32)
> (In reply to Hauke Mehrtens from comment #29)
> > I do not recall that any usage of libcrypt was changed in this refactoring,
> > most of this stuff was cleaning up some hard to understand code and unifying
> > some dtls and ssl stuff.
> > 
> > Would it be possible for someone to bisect this problem so we get to know
> > which commit fixed this problem.
> 
> master branch does not crash simply most probably because
> aa09feaf52f842adcf70aca60409281e5739ec08 changed the time where
> ssl_generate_keyring_material() funtion is called (it is no more done when
> receiving the ServerHello).
> Now what I can see is that depending on the compiler used when building a
> Win32 Wireshark, we get different results:
> - with MSVC2010, the memory corruption is detected at the end of the capture
> processing because the heap of except_pop() got corrupted
> - with MSVC2013, we catch an invalid memory access when calling
> gcry_cipher_setkey() with parameters that do look valid
> - I was not able to reproduce the issue on Linux
> 
> What I suspect is that there is something wrong with the libgcrypt library
> that we get from OBS, but I did not find a way to load the gcc debug symbols
> in my MSVC debugger.
> Switching back to GnuTLS 2.12.18 / Gcrypt 1.4.6 does not crash.
> 
> I will probably try to compile myself a libgcrypt library to see what
> happens.

I tried compiling a libgcrypt library using MSVC++ but it was too painful. I
also reverted back to GnuTLS 2.12.18 and it seems stable.


You are receiving this mail because:
  • You are watching all bug changes.