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

 
 

bug #18799: targa core dump

Submitter:  TSP administrator <tsp_admin>
Submitted:  Tue 16 Jan 2007 12:25:01 PM UTC
   
 
Category:  Targa/GDisp+ Severity:  4 - Important
Status:  In Progress Privacy:  Public
Assigned to:  erk Open/Closed:  Closed
Release:  * 0.8.2 Fixed Release:  * 0.8.3
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator

 

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

Attach Files:
   
   
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
  • -email is unavailable- added by esteban (Posted a comment)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by tsp_admin (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-04-27 erk Open/ClosedOpen Closed
        Fixed Release0.9.0 0.8.3
    2007-02-10 erk StatusNone In Progress
        Assigned toNone erk
        Carbon-Copy- Added esteban
    2007-02-10 erk Carbon-CopyRemoved euskadi -
    2007-01-24 erk Assigned toesteban None
        Carbon-Copy- Added euskadi
    2007-01-16 tsp_admin Attached File- Added bug_targa.txt, #11764

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code