Mailing List Archive: RE: Assert in print.c get_field

RE: Assert in print.c get_field_data() creating PD ML file

Jun 2, 2006, 6:41 AM

Post #1 of 4 (2084 views)

I'm using a "real data" tvbuff.

-----Original Message-----
From: ethereal-dev-bounces@ethereal.com [mailto:ethereal-dev-bounces@ethereal.com] On Behalf Of Gilbert Ramirez
Sent: 02 June 2006 14:31
To: Ethereal development
Subject: Re: [Ethereal-dev] Assert in print.c get_field_data() creating PDML file

On what data is the tvbuff created? Is it a sub-set of a previous
tvbuff, or is it a "modification" (decompression, decryption) of
previous tvbuff data? I.e., are you using a "subset" tvbuff or a "real
data" tvbuff?

--gilbert

On 6/2/06, Howlett, James (James) <jameshowlett@lucent.com> wrote:
>
>
>
>
> Hi,
>
>
>
> If I create a tvbuff, and do not use add_new_data_source(), but reference it
> in elements added to the proto tree; then I reach "g_assert_not_reached()"
> in get_field_data() in print.c when exporting to PDML. I'm currently using
> ethereal 0.99.0.
>
>
>
> Is there any good reason for this assert?
>
> By default I do not wish to use add_new_data_source() - it appears to add a
> significant amount of overhead, and since I am often using large captures
> any reduction in overhead is a good thing J
>
>
>
> BTW Within our company we've been using a modified version of ethereal as a
> replacement for commercial protocol analysers, for monitoring traffic within
> 3G networks. It makes the commercial analysers look very poor value for
> money.
>
> I need to look through the modifications I've made to some of the existing
> protocols, and contribute some of my changes (eg how 'connections' are
> tracked within SCCP and ALCAP). Not least because otherwise I'll just have
> to keep doing merges every time a new version is released.
>
>
>
> Cheers,
>
>
>
> James.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Re: Assert in print.c get_field_data() creating PD ML file [ In reply to ]

gram at alumni

Jun 6, 2006, 5:19 AM

Post #2 of 4 (1990 views)

Permalink

My only idea there is to ask if you used
tvb_set_child_real_data_tvbuff() to attach the real data tvbuff to the
real/subset chain passed to your dissector.

--gilbert

On 6/2/06, Howlett, James (James) <jameshowlett@lucent.com> wrote:
>
> I'm using a "real data" tvbuff.
>
> -----Original Message-----
> From: ethereal-dev-bounces@ethereal.com [mailto:ethereal-dev-bounces@ethereal.com] On Behalf Of Gilbert Ramirez
> Sent: 02 June 2006 14:31
> To: Ethereal development
> Subject: Re: [Ethereal-dev] Assert in print.c get_field_data() creating PDML file
>
> On what data is the tvbuff created? Is it a sub-set of a previous
> tvbuff, or is it a "modification" (decompression, decryption) of
> previous tvbuff data? I.e., are you using a "subset" tvbuff or a "real
> data" tvbuff?
>
> --gilbert
>
> On 6/2/06, Howlett, James (James) <jameshowlett@lucent.com> wrote:
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > If I create a tvbuff, and do not use add_new_data_source(), but reference it
> > in elements added to the proto tree; then I reach "g_assert_not_reached()"
> > in get_field_data() in print.c when exporting to PDML. I'm currently using
> > ethereal 0.99.0.
> >
> >
> >
> > Is there any good reason for this assert?
> >
> > By default I do not wish to use add_new_data_source() - it appears to add a
> > significant amount of overhead, and since I am often using large captures
> > any reduction in overhead is a good thing J
> >
> >
> >
> > BTW Within our company we've been using a modified version of ethereal as a
> > replacement for commercial protocol analysers, for monitoring traffic within
> > 3G networks. It makes the commercial analysers look very poor value for
> > money.
> >
> > I need to look through the modifications I've made to some of the existing
> > protocols, and contribute some of my changes (eg how 'connections' are
> > tracked within SCCP and ALCAP). Not least because otherwise I'll just have
> > to keep doing merges every time a new version is released.
> >
> >
> >
> > Cheers,
> >
> >
> >
> > James.
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@ethereal.com
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> >
> >
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

RE: Assert in print.c get_field_data() creating PD ML file [ In reply to ]

jameshowlett at lucent

Jun 7, 2006, 1:44 AM

Post #3 of 4 (1989 views)

Permalink

I am currently using tvb_set_child_real_data_tvbuff().

The issue is that get_field_data() in print.c iterates through the list of data sources to get the bytes referred to by a field_info.

I don't believe that removing the g_assert_not_reached() will have any negative side effects. It will simply mean that no bytes are printed if the tvb has not been added via add_new_data_source(). But I am not that familiar with the source code so I could be wrong.

James.

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Re: Assert in print.c get_field_data() creating PD ML file [ In reply to ]

gram at alumni

Jun 8, 2006, 1:20 PM

Post #4 of 4 (1989 views)

Permalink

Can you use add_new_data_source? That seems to be the way to do
things, looking at other dissectors. Call
tvb_set_child_real_data_tvbuff() to link the tvbuff ot the others,
then call add_new_data_source() so the data source can be shown in the
hex-dump pane of the GUI.

--gilbert

On 6/7/06, Howlett, James (James) <jameshowlett@lucent.com> wrote:
>
> I am currently using tvb_set_child_real_data_tvbuff().
>
> The issue is that get_field_data() in print.c iterates through the list of data sources to get the bytes referred to by a field_info.
>
> I don't believe that removing the g_assert_not_reached() will have any negative side effects. It will simply mean that no bytes are printed if the tvb has not been added via add_new_data_source(). But I am not that familiar with the source code so I could be wrong.
>
> James.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev