Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 45445: /trunk/epan/ /trunk/epan/: em

From: Evan Huus <eapache@xxxxxxxxx>
Date: Wed, 10 Oct 2012 09:32:07 -0400
On Wed, Oct 10, 2012 at 8:53 AM, Jakub Zawadzki
<darkjames-ws@xxxxxxxxxxxx> wrote:
> On Wed, Oct 10, 2012 at 08:32:00AM -0400, Evan Huus wrote:
>> On Wed, Oct 10, 2012 at 8:24 AM,  <darkjames@xxxxxxxxxxxxx> wrote:
>> > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=45445
>> >
>> > User: darkjames
>> > Date: 2012/10/10 05:24 AM
>> >
>> > Log:
>> >  Fix bug #7814
>> >
>> >  We need to pass original pointer and length to munmap().
>> >
>> > Directory: /trunk/epan/
>> >   Changes    Path          Action
>> >   +8 -4      emem.c        Modified
>>
>> Ahah, this all makes sense to me now, thank you for the fix!
>>
>> Although how did struct emem_chunk_t end up with two different members
>> named "org"? Is that some intentional type-masking that I don't
>> understand, or is it just a typo?
>
> Short story how to make development wireshark paintful.
> Two machines:
>   A - laptop (faster, without ssh keys) development
>   B - desktop (slower, with ssh keys) commiting
>
> A: git repository
>   ## coding, coding, coding..
>   ## compiles, great.
>   $ git diff > /tmp/a.patch
>
> B:
>   scp 10.XX:/tmp/a.patch /tmp/
>   $ patch -p2 < /tmp/a.patch
>   patching file emem.c
>   Hunk #2 succeeded at 310 (offset 1 line).
>   Hunk #3 succeeded at 671 (offset 1 line).
>   Hunk #4 succeeded at 683 (offset 1 line).
>   ## WTF, why with offset?!
>
>   $ svn diff
>   ## looks good
>   $ svn commit
>   typing, typing, typing
>   :wq
>
>   Committed revision 45445.
>
>   (looking at commit on wireshark-commit...)
>
>   Committed revision 45446.
>
>
> Well, main problem is that I don't have building env on machine B,
> and I can't test if it compiles before commiting...
>
>
> Anyway I hope this fix is temporary, right?

The fix is needed regardless of what else happens - even with the old
old allocator this was still a bug (in the sl_ allocator, if not the
ep_ one), we just weren't using enough pages to hit it. However, once
I land proper sharing of free pages between pools then this path will
probably stop being hit again (just like before).

I don't want to make promises I can't keep, but I have an idea I'm
pretty sure will work, and Thursday evening is looking promising for
time to implement it. I'll make sure to test with both allocation
schemes this time though!

Cheers,
Evan