bugTransport Sample Protocol - Bugs: bug #18799, targa core dump

 
 

bug #18799: targa core dump

Submitted by:  TSP administrator <tsp_admin>
Submitted on:  Tue 16 Jan 2007 12:25:01 PM UTC  
 
Category: Targa/GDisp+Severity: 4 - Important
Status: In ProgressPrivacy: Public
Assigned to: Eric NOULARD <erk>Open/Closed: Closed
Release: 0.8.2Fixed Release: 0.8.3

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 12 Feb 2007 08:11:51 PM UTC, comment #5:

You are completely right.
This is an old piece of code I forgot to update.

This is done now.
All TSP_consumer_xxx function calls have been checked in TARGA.

All returned error code are now compared to TSP_STATUS_xxx enumerated values.

Euskadi.

Stephane Venerque <esteban>
Project Member
Sat 10 Feb 2007 06:49:01 PM UTC, comment #4:

I partially correct the bug.
We should always verify wether ans_sample is non NULL
before going on.

Nevertheless targa's code seems doing something wrong.
here is the code excerpt from gdisp_sampling.c:939
(in gdisp_samplingThread )

>>

provider->pSamplingThreadStatus = GD_THREAD_STOPPED;

/*
* Tell TSP core to stop sampling process.
*/
if (requestStatus == FALSE) {
requestStatus = 0;
}
else {
requestStatus = TSP_consumer_request_sample_destroy(provider->pHandle);
}

if (TSP_STATUS_OK != requestStatus) {

provider->pSamplingThreadStatus = GD_THREAD_SAMPLE_DESTROY_ERROR;

}

>>


When stopping sample targa compares requestStatus
with FALSE which is not an acceptable value
for requestStatus which should be compared with
TSP_STATUS_xxx values.

This compiles fine since FALSE is #defined to (0)
and TSP_STATUS_xxx is an enum value.

Nonetheless
FALSE == 0
and
TSP_STATUS_OK == 0

which means targa would never call
TSP_consumer_request_sample_destroy

which is a bad idea even if provider died.

After that when you press targa "start sampling"
button again the process gets a SIGPIPE after
an RPC error.

RPC error is OK since RPC server died and RPC
client has a dangling connection to it.

Now I don't know why we get SIGPIPE for this...
I commit the change in TSP core for proper
check of NULL value for ans_sample.
I have added better returned value for
TSP_consumer_read_sample when provider died.

Euskadi may re-read the code of gdisp_sampling.c
of targa in order to seek;

(requestStatus == FALSE) and may be put
a valid code check.

I may do it myself but may be you want to do
an overall check for this kind of things in targa.

The check against FALSE/TRUE has been right in the past
but nowadays all tsp_consumer_xxx functions should return
TSP_STATUS_xxx codes unless they return typed "values" like:
TSP_consumer_get_channel_id
or
TSP_consumer_get_connected_name

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 24 Jan 2007 08:28:22 AM UTC, comment #3:

I "unassign" Euskadi from this "bug"
since he may not be the person who will fix it.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 17 Jan 2007 09:03:50 PM UTC, comment #2:

OK right.
This is more like tsp consumer lib bug.
Each tsp_consumer_xxx should be protected by a
session validity check.

The correct behavior should be

throw a TSP error code

I will dive into the code in order to see
whether it's a lot of work to do this or not.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 17 Jan 2007 08:57:58 PM UTC, comment #1:

Comment from Euskadi which should have been posted
on the tracker (in the first place).

http://lists.nongnu.org/archive/html/tsp-devel/2007-01/msg00015.html

>>

Agur,

There is not need to perform any investigation.

The problem is the following one : how can a tsp-client be sure that
the tsp-provider is still alive before using any TSP function ?

By the way, the core occurs inside a TSP-function of the TSP-consumer library.
Targa completely relies on this library without any means to check the
availability of the provider.

Euskadi.

PS : For those who do not speak Basque, "Agur" stands for "Hi".

>>

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Tue 16 Jan 2007 12:25:01 PM UTC, original submission:

Hello all.

I discoverd a very simple but quit nasty bug in TARGA !

Here is how to reproduce it :
- open a conexion to the tsp_stub_server (all hosts on linux)
- add some data to view/plot
- start then stop the drawing.
- kill the stub.
- click on start in Targa
=> and targa exit with segmentation fault.

I add the TARGA's stack for further investigation.

Except this, TARGA is still very nice.
Yves

TSP administrator <tsp_admin>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #11764:  bug_targa.txt added by tsp_admin (1KiB - text/plain - Soon fixed or not ?)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by esteban (Posted a comment)
  • -unavailable- added by erk (Posted a comment)
  • -unavailable- added by tsp_admin (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 27 Apr 2007 11:15:52 AM UTCerkOpen/ClosedOpen=>Closed
      Fixed Release0.9.0=>0.8.3
    Sat 10 Feb 2007 06:49:01 PM UTCerkStatusNone=>In Progress
      Assigned toNone=>erk
      Carbon-Copy-=>Added esteban
    Sat 10 Feb 2007 06:16:50 PM UTCerkCarbon-CopyRemoved euskadi=>-
    Wed 24 Jan 2007 08:28:22 AM UTCerkAssigned toesteban=>None
      Carbon-Copy-=>Added euskadi
    Tue 16 Jan 2007 12:25:01 PM UTCtsp_adminAttached File-=>Added bug_targa.txt, #11764

    Back to the top


    Powered by Savane 3.1-cleanup1