Re: allocator->in_scope

[Paul Offord <Paul.Offord () advance7 com>]

Even bigger aha.  Although I only have one new block in the pcapng file, when I open the file via the file explorer 
dialogue, my block reader is called twice; once to allow WS to enrich the dialogue box (I think) and a second time to 
read the block before dissection.  I never noticed this before, and this probably explains a few weird problems I have 
been grappling with.

I know you are gripped by this drama, so I'll let you know what I find.

From: Wireshark-dev <wireshark-dev-bounces () wireshark org> On Behalf Of Paul Offord
Sent: 25 March 2018 17:20
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Subject: Re: [Wireshark-dev] allocator->in_scope

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<mailto: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
______________________________________________________________________

______________________________________________________________________

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