Add a New Comment (Rich Markup)
( Jump to the original submission )
Update bad CC. Now it should be correct
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.
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.)
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)
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).
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
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
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11