bugTransport Sample Protocol - Bugs: bug #19706, Segfault or bad retcode when...

 
 

bug #19706: Segfault or bad retcode when provider is unreachable

Submitted by:  Eric NOULARD <erk>
Submitted on:  Thu 26 Apr 2007 11:06:22 AM UTC  
 
Category:  Core Severity:  4 - Important
Status:  Ready For Test Privacy:  Public
Assigned to:  Eric NOULARD <erk> Open/Closed:  Open
Release:  Unknown Fixed Release:  CVS

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)

Sat 12 May 2007 11:49:15 PM UTC, comment #7: 

I have just committed the change to CVS.
Now tsp consumer side check for more RPC error
and in particular when the first "FATAL" RPC error
occurs the corresponding provider goes in the
"UNREACHABLE" state and won't go out of it.

The side effect is:

1) you get proper TSP_STATUS_xxxx code
   from every TSP_consumer_request_xxxx

2) you application/thread does not dies
   on second RPC error because we received SIGPIPE

  

3) you won't be able to use a provider which goes
   "UNREACHABLE"
   you'll have to start over the TSP session
   beginning at TSP_consumer_connect_url.

You'll find a patch against 0.8.3 source tree attached
to the tracker.
The corresponding patch already reached CVS.

(file #12758)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Sat 12 May 2007 04:25:53 PM UTC, comment #6: 

OK right.
Now I see.
However as far as I understand
the trouble is not on the server-side as you
suggest about the function

tsp_request_close_1_svc() in tsp_server.c

in your case the server (i.e. provider) is dead
(or "networkly" unreachable)
and you want the consumer to handle this.

I am currently trying a fix which seems to work.
You will have a patch to try soon.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 11 May 2007 12:15:02 PM UTC, comment #5: 

Hello,

Concerning your precedent remark, you're right.In fact, when i put strace_debug to 15 , i look a trace which indicates that retcode is NULL.

I try to investigate about this problem. I think that you may be modify the structure of the method tsp_request_close_1_svc() in tsp_server.c . This method puts at the beginning retcode to 0 and then this value is never update.That's why , when scoe is unreachable, the status is always TSP_STATUS_OK.
I think one solution is to do like the method tsp_request_open_1_svc(). I think it's better to return a structure like TSP_answer_open_t than an integer and to update the value of structure.

If you have time ....
Thanks
---
Sarah

montigaud <sarah_montigaud>
Wed 09 May 2007 07:10:12 PM UTC, comment #4: 

May be you should try to debug the code inside a debugger
in order to check the return value of
TSP_request_close, nevertheless.

your STRACE_DEBUG call may be OK but you should check
if STRACE_DEBUG  mask value includes 8 (4th bit)

for example STRACE_DEBUG=15 implies

  • WARNING --> 1
  • INFO    --> 2
  • REQUEST --> 4
  • DEBUG   --> 8

You could check values in

tsp/src/core/include/tsp_simple_trace.h

Moreover since you get the message:

ERROR||/home/intocv61/VAla/TSP_0.8.3/sources/src/core/rpc/tsp_client.c##TSP_request_close##208: : RPC: Unable to receive; errno = Connection reset by peer

And that message comes from the macro:

#define TSP_STRACE_RPC_ERROR(cl, pResult) if(!pResult)  {  STRACE_ERROR(("%s", clnt_sperror(cl, "")));  }

called in

tsp_client.c:208
TSP_STRACE_RPC_ERROR(server, retcode);

I would say that retcode is NULL
but your STRACE_DEBUG is not displayed because the debug
level is not activated by the STRACE_DEBUG mask value.

Stepping in TSP source code may seems hard, but
as soon as you did somes more steps
you may find it easy ;=)

Thank you for making this first step, you should go on :=)

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Wed 09 May 2007 03:28:28 PM UTC, comment #3: 

hello,

I try to change the code of TSP in version 0.8.3 src/core/driver/tsp_consumer.c:750

I make this change:

 

int *result;
  result = TSP_request_close(&req_close, otsp->server);
  if (result) {
    retcode = *result;
  } else {
      STRACE_DEBUG(("result is <0x%X>\n", (unsigned int) result)); }

Then, i test it and it doesn't work.My TSP trace is
TSP: Request||/home/intocv61/VAla/TSP_0.8.3/sources/src/core/driver/tsp_consumer.c##TSP_consumer_request_close##742: CLOSE
  ERROR||/home/intocv61/VAla/TSP_0.8.3/sources/src/core/rpc/tsp_client.c##TSP_request_close##208: : RPC: Unable to receive; errno = Connection reset by peer

If you have an idea


Sarah

montigaud <sarah_montigaud>
Wed 09 May 2007 01:02:50 PM UTC, comment #2: 

italic
Hello world,
Concerning the bug 19706, i would like to know what's new about it.
Now, with virgine , we work on TSP version 0.8.3. The problem with >request_sample() core dump is solved.(thanks for correction)
italic


Good to known :))


italic
But, with this new version, i try to test the tsp_request_close() when the provider is unreachable.The status of this request is TSP_status_OK and no TSP_STATUS_ERROR_PROVIDER_UNREACHABLE.

If you have time, is it possible to correct it ?
italic


I am currently being tight in time
may be you could try it yourself and I will be pleased
to review your proposed patch?

Would you have time to give it a try?

You may follow the

TSP_consumer_request_close

function call from
src/core/driver/tsp_consumer.c:750

I think we should check the return value
of the effective rpc call:

TSP_request_close(&req_close, otsp->server);

tell me if you want to try.

bold: please use the tracker (instead of the list)
        for this bug follow-up

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Fri 27 Apr 2007 07:59:26 AM UTC, comment #1: 

Sarah,

As noted by Fred
http://lists.nongnu.org/archive/html/tsp-devel/2007-04/msg00054.html

The request_sample "core dump" problem should not exist
in TSP 0.8.3 anymore.
Could you check the TSP version you are using?

You could check which version of TSP you are using
(at compile time) by using the MACRO:

TSP_SOURCE_VERSION which is defined in tsp_prj.h
which is icnluded by any TSP-enabled application.

we should add a

const char* tsp_get_source_version() {
  return TSP_SOURCE_VERSION;
}

API but in the meantime, you could use the MACRO
value directly.

This would be a very important piece of information
for everybody (TSP user and/or developer) in order to track
down issues.

In fact I previously assumed you were running TSP 0.8.3
but it seems that it is not the case.

I switch the TSP version for this bug to unknown until
you (Sarah) confirm the version.

Eric NOULARD <erk>
Project AdministratorIn charge of this item.
Thu 26 Apr 2007 11:06:22 AM UTC, original submission:  

If we run a provider and a consumer and
the consumer tries to use TSP_request_xxx while the
provider is dead (or unreachable, or terminated etc...)

we get:

a segfault on TSP_consumer_request_sample.
a wrong TSP_STATUS_OK on TSP_consumer_request_close.

all TSP_consumer_request xxx should return:
TSP_STATUS_ERROR_PROVIDER_UNREACHABLE

in this case.

see discussion on ML:
http://lists.nongnu.org/archive/html/tsp-devel/2007-04/msg00053.html
http://lists.nongnu.org/archive/html/tsp-devel/2007-04/msg00052.html

Eric NOULARD <erk>
Project AdministratorIn charge of this item.

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #12758:  bug19706-badretcode-erk-1.patch added by erk (10KiB - text/x-patch - More effective handling of RPC error)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sarah_montigaud (Posted a comment)
  • -email is unavailable- added by erk (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-05-12 erk Attached File- => Added bug19706-badretcode-erk-1.patch, #12758
        StatusIn Progress => Ready For Test
        Fixed ReleaseUnknown => CVS
    2007-05-12 erk StatusNone => In Progress
    2007-05-09 erk Assigned toNone => erk
    2007-04-27 erk Release0.8.3 => Unknown
    2007-04-26 erk Carbon-Copy- => Added ext.zxopesoge001@astrium.eads.net

    Back to the top


    Powered by Savane 3.5