bugTransport Sample Protocol - Bugs: bug #22115, targa crash when starting...

 
 

bug #22115: targa crash when starting acquisition

Submitted by:  Robert de Vries <rhdv>
Submitted on:  Fri 25 Jan 2008 03:21:39 PM UTC  
 
Category:  Core Severity:  4 - Important
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Release:  0.8.3 Fixed Release:  Unknown

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

( Jump to the original submission)

Mon 04 Feb 2008 09:48:57 PM UTC, comment #6: 

Update bad CC.
Now it should be correct

Eric NOULARD <erk>
Project Administrator
Mon 04 Feb 2008 09:47:23 PM UTC, comment #5: 

Nice the improved implementation for STRACE :=)

I think there is 2 troubles in your bug:

1) The sent request_sample get a ERROR state answer_sample
   because the provider said: 
   "symbols error"

   For this one you need to activate STRACE_DEBUG on the
   provider side
   (may be in the terminal where the provider is launched)
   in order to see which symbol(s) make the request invalid.

   Did you implement your own GLU?
   Can you reproduce the bug with targa + stub server?

2) Targa seems to ignore the bad anwser?
   Seems odd since I can read
   in gdisp_sampling.c:gdisp_requestSample
   that the retcode is checked.

   may be the caller(s) of gdisp_requestSample
   does not check gdisp_requestSample retcode :=)

  

I do add euskadi as a CC for the second issue.

Eric NOULARD <erk>
Project Administrator
Mon 04 Feb 2008 09:40:36 PM UTC, comment #4: 

OK I figured this one out. It seems that the targa configuration file was bad. It seems that a couple of variables were incorrectly typed as F64 when they were in reality I32.
However, I still think this should have been caught by targa. Some checking of input files is needed. It is IMHO always possible that some symbols may change type on the provider side and targa should be robust against that.
Theoretically you should not even have to store the type, because you can easily query it at start-up. (If you have to check, you can just as well use the result in the first place.)

Robert de Vries <rhdv>
Project Member
Mon 04 Feb 2008 09:10:56 PM UTC, comment #3: 

Another trace, but now with all traces enabled:
export STRACE_DEBUG=0xff (see what my new and improved implementation offers.... cool hex number parsing)

Anyway here is the trace:
   Info||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_end##444: TSP Consumer End...
   Info||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_connect_url##527: Trying to connect to <rpc://localhost/:0>
   Info||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/rpc/tsp_client.c##tsp_remote_open_progid##82: CONNECTED to server localhost
   Info||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/rpc/tsp_client.c##TSP_remote_open_server##132: Server opened : 'EuroSim'
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_open##685: OPEN
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_filtered_information##842: FILTERED INFORMATION
  Debug||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_store_informations##194: Number of symbols found in answer = 0
   Info||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_store_informations##195: Provider base frequency = 100.000000 Hz
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1001: SAMPLE
Warning||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1043: Provider symbols error
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1001: SAMPLE
Warning||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1043: Provider symbols error
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample_init##1137: SAMPLE INIT
  Debug||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample_init##1147: data_address = 'on_time'

What I do is that I start targa as follows:
targa -x targa_conf.xml
I have attached the config file for your convenience below in the bug report screen.

(file #14960)

Robert de Vries <rhdv>
Project Member
Mon 04 Feb 2008 09:04:39 PM UTC, comment #2: 

Below you find a trace of a crashing run with STRACE_DEBUG set to 4:
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_open##685: OPEN
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_filtered_information##842: FILTERED INFORMATION
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1001: SAMPLE
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample##1001: SAMPLE
Request||/home/rhdv/src/tsp-build/RPM/BUILD/tsp-0.8.4cvs-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample_init##1137: SAMPLE INIT
Segmentation fault (core dumped)

This is against the current CVS version of the TSP library, with my trace patches already in place. (But this output just shows that everything works as expected, yet another test passed).

Robert de Vries <rhdv>
Project Member
Fri 25 Jan 2008 06:48:45 PM UTC, comment #1: 

Hi Robert,

TSP_STATUS_ERROR_BAD_REQUEST_ORDER

usually means a consumer did not respect the
TSP request automaton:
http://cvs.savannah.nongnu.org/viewvc/*checkout*/tsp_docs/tsp_specs/tsp_consumer_state.dia?revision=1.1&root=tsp

(I should check if the diagram is still
 up to date or not)

For example

1) request_open
2) request_sample_init

will fail because of the missing request_sample before
request_sample_init

you may get this too if
1) request_open
2) request_sample
3) request_sample_init

but the the result of the good-ordered request_sample
is an error because some symbols were not recognized
in the request_sample.

etc...

as a last guess I would say that un-synchronized thread
(in the consumer) may cause this too.

If you want to trace the TSP_Request sent by the consumer
you may
export STRACE_DEBUG=4

Eric NOULARD <erk>
Project Administrator
Fri 25 Jan 2008 03:21:39 PM UTC, original submission:  

Targa crashes with the following stack trace when starting acquisition using a predefined configuration file.

#0  0x00b8bdae in ____strtol_l_internal () from /lib/libc.so.6
#1  0x00b8bb57 in __strtol_internal () from /lib/libc.so.6
#2  0x00b89391 in atoi () from /lib/libc.so.6
#3  0x006a7412 in TSP_stream_receiver_create (data_address=0x920a248 "")
    at /home/rv62021/rpmbuild/BUILD/tsp-0.8.3-Source/src/core/driver/tsp_stream_receiver.c:87
#4  0x0069f0bc in TSP_data_receiver_create (data_address=0x920a248 "", callback=0, user_data=0x0)
    at /home/rv62021/rpmbuild/BUILD/tsp-0.8.3-Source/src/core/driver/tsp_data_receiver.c:136
#5  0x006a50c4 in TSP_consumer_request_sample_init (provider=0x921ae08, callback=0, user_data=0x0)
    at /home/rv62021/rpmbuild/BUILD/tsp-0.8.3-Source/src/core/driver/tsp_consumer.c:1123
#6  0x080605a8 in gdisp_samplingThread (data=0x91f6688)
    at /home/rv62021/rpmbuild/BUILD/tsp-0.8.3-Source/src/consumers/gdisp+/gdisp_sampling.c:820

The problem is traced to an error code returned by TSP_data_receiver_create() that is not handled in TSP_consumer_request_sample_init() before line 1123 where the above mentioned function TSP_data_receiver_create() is called with a data_address parameter that is "" (ie. the empty string). The reply from TSP_request_sample_init() in ans_sample is:
{version_id = 65537, channel_id = 3, data_address = 0x920a248 "", status = TSP_STATUS_ERROR_BAD_REQUEST_ORDER}
The status seems to indicate that something went wrong, but the code doesn't seem to care.
The

Robert de Vries <rhdv>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #14960:  targa_conf.xml added by rhdv (2KiB - text/xml - The targa config file I mentioned above.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by erk (For targa bug)
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by rhdv (Submitted the item)
  •  

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

    Only logged-in users can vote.

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-02-04 erk Carbon-Copy- => Added esteban
    2008-02-04 erk Carbon-CopyRemoved euskadi => -
    2008-02-04 erk Carbon-Copy- => Added euskadi
    2008-02-04 rhdv Attached File- => Added targa_conf.xml, #14960

    Back to the top


    Powered by Savane 3.5