Re: allocator->in_scope

[Evan Huus <eapache () gmail com>]

Hi Paul, that’s an interesting case you’ve found. The file scope was
definitely intended for file-scoped dissection memory (which is why it is
enabled in init_dissection() and not earlier in the file lifecycle) but I
can definitely see the use for it in writing a block reader too.

I think it is probably worth figuring out where it ends up being called in
the case that crashes (since it must get called at some point just too
late), find the common ancestor, and move the enter_file_scope call there.
As long as each enter call always still has a single matching exit it
should be fine to enter file scope a bit sooner.

Alternatively you could create a new scope object explicitly attached to
the file struct and make that the eventual long-term file scope, since I
still have a pipe dream of getting rid of the scope globals entirely in
order to let Wireshark handle multiple files at once.

Evan

On Sun, Mar 25, 2018 at 12:20 Paul Offord <Paul.Offord () advance7 com> wrote:

> Aha – whilst what I’ve written below is true, it doesn’t accurately
> reflect the issue.
>
>
>
> If I start Wireshark and double click on a file in the recently opened
> list, part of the processing is this:
>
>
>
>   cf_open() calls
>
>     ws_epan_new() calls
>
>       epan_new() calls
>
>         init_dissection() calls
>
>           wmem_enter_file_scope() which sets
>
>             file_scope->in_scope = TRUE;
>
>
>
> All of the above takes place before my new block reader is called.
>
>
>
> If I start Wireshark, use Ctl-O and then double click on a file in the
> file explorer dialogue, there is no call to wmem_enter_file_scope() before
> my block reader is called.
>
>
>
> I believe this is a bug.  The two file opens should be consistent in the
> setting of file_scope->in_scope = TRUE, and hence the scope of
> wmem_file_scope().
>
>
>
>    - Am I wrong?
>    - Have I missed something?
>    - Should I create a bug report?
>
>
>
> Thanks and regards…Paul
>
>
>
> *From:* Paul Offord
> *Sent:* 25 March 2018 10:31
> *To:* Developer support list for Wireshark <wireshark-dev () wireshark org>
> *Subject:* allocator->in_scope
>
>
>
> Hi,
>
>
>
> Still working on my new block reader.  To recap, I’ve defined a new pcapng
> block type and written a dissector.  The first thing I have to do is read
> the new block type, and Wireshark provides a framework to do this.  In the
> new block reader I define some space like this:
>
>
>
>             tdb_namespace = wmem_strdup_printf(wmem_file_scope(), "%s",
> option_block->option_data);
>
>
>
> Eventually the wmem_strdup_printf(…) execution calls this function:
>
>
>
> void *
>
> wmem_alloc(wmem_allocator_t *allocator, const size_t size)
>
> {
>
>     if (allocator == NULL) {
>
>         return g_malloc(size);
>
>     }
>
>
>
>     if (!allocator->in_scope) // debug code
>
>         while (FALSE); // debug code
>
>
>
>     g_assert(allocator->in_scope);
>
>
>
>     if (size == 0) {
>
>         return NULL;
>
>     }
>
>
>
>     return allocator->walloc(allocator->private_data, size);
>
> }
>
>
>
> The g_assert intermittently fails.  If I open one file containing the new
> block, allocator->in_scope is true.  If I call another it’s false.
>
>
>
> The block read is called before we start dissecting the contents with the
> dissector code.
>
>
>
>    - At what point is wmem_file_scope in scope?
>    - Should it be when my block reader is called or is it only guaranteed
>    when the dissector code is called?
>
>
>
> Thanks and regards…Paul
>
>
>
> ______________________________________________________________________
>
> This message contains confidential information and is intended only for
> the individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system.
>
> Any views or opinions expressed are solely those of the author and do not
> necessarily represent those of Advance Seven Ltd. E-mail transmission
> cannot be guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> contain viruses. The sender therefore does not accept liability for any
> errors or omissions in the contents of this message, which arise as a
> result of e-mail transmission.
>
> Advance Seven Ltd. Registered in England & Wales numbered 2373877 at
> Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe