Alebu, Can you put those generated code inside #ifndef __cplusplus... declaration and try. I mean not only headers but also the implementation inside one #ifndef __cplusplus... block. Since you are using g++ as the compiler this may solve the problem. Because WSDL2C tool may be assuming that default compiler is gcc.
Thanks, -Manjula. On Thu, 2008-04-24 at 11:51 +0200, alebu wrote: > I only had one additional function and it is declared (in header file) > in suggested #ifndef __cplusplus... > I even removed it and all calls to it (only one call actually), but > result is the same. > All other code is generated with WSDL2C utility. There was problems > with it too (there is a thread about it), > but they was solved. So code is purely generated by WSDL2C. > When I turn on linker option "do not use default > libraties" (-nodefaultlibs) > Segmentaion Fault turned into SOAP response: > > <soapenv:Envelope > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> > <soapenv:Header/> > <soapenv:Body> > <soapenv:Fault> > <faultcode>soapenv:Server</faultcode> > <faultstring>Failed in creating DLL</faultstring> > </soapenv:Fault> > </soapenv:Body> > </soapenv:Envelope> > > And in logs/axis2.log I have naow: > [Thu Apr 24 12:42:36 2008] [debug] req_uri_disp.c(100) Checking for > service using target endpoint address : > http://127.0.0.1:9090/axis2/services/uniservice > [Thu Apr 24 12:42:36 2008] [debug] req_uri_disp.c(121) Service found > using target endpoint address > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > AddressingInHandler within the phase Transport > [Thu Apr 24 12:42:36 2008] [info] Starting addressing in handler > [Thu Apr 24 12:42:36 2008] [info] addr_in_handler.c > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > addressing_based_dispatcher within the phase Transport > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > rest_dispatcher within the phase Dispatch > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > soap_message_body_based_dispatcher within the phase Dispatch > [Thu Apr 24 12:42:36 2008] [debug] soap_body_disp.c(231) Checking for > operation using SOAP messagebody's first child's local name : serve > [Thu Apr 24 12:42:36 2008] [debug] soap_body_disp.c(240) Operation > found using SOAP message body's first child's local name > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > soap_action_based_dispatcher within the phase Dispatch > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > dispatch_post_conditions_evaluator within the phase PostDispatch > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > context_handler within the phase PostDispatch > [Thu Apr 24 12:42:36 2008] [warning] op.c(1149) Message id not found > for message context while registering operation context for operation > serve > [Thu Apr 24 12:42:36 2008] [error] class_loader.c(161) dlerror > reason: ..//services/uniservice/libuniservice.so: undefined symbol: > __gxx_personality_v0 > [Thu Apr 24 12:42:36 2008] [error] raw_xml_in_out_msg_recv.c(115) Impl > object for service 'uniservice' not set in message receiver. 101 :: > Failed in creating DLL > [Thu Apr 24 12:42:36 2008] [debug] phase.c(210) Invoke the handler > AddressingOutHandler within the phase MessageOut > [Thu Apr 24 12:42:36 2008] [info] Starting addressing out handler > [Thu Apr 24 12:42:36 2008] [debug] addr_out_handler.c(133) No action > present. Stop processing addressing > [Thu Apr 24 12:42:36 2008] [info] Request served in 0.123 seconds > [Thu Apr 24 12:45:15 2008] [info] Received signal SIGINT. Server > shutting down > [Thu Apr 24 12:45:15 2008] [info] Terminating HTTP server thread > [Thu Apr 24 12:45:15 2008] [debug] http_svr_thread.c(181) Terminating > HTTP server thread. > [Thu Apr 24 12:45:15 2008] [info] Successfully terminated HTTP > server thread > [Thu Apr 24 12:45:15 2008] [info] Shutdown complete ... > > > On Thu, Apr 24, 2008 at 10:40 AM, Manjula Peiris <[EMAIL PROTECTED]> > wrote: > Hi Alebu, > > The segfault comes from AXIS2_SVC_SKELETON_INIT macro. So this > is > because when calling your svc_skeleton_init function. Since > you are > using g++ and given that it worked for gcc the only reason I > can think > of is missing, > #ifdef __cplusplus > extern "C" { > #endif > > > declaration. Since you have that already there I can't think > of any > valid reason from the provided details. So in order to analyze > further > can you send us your web services code. > > Thanks, > -Manjula. > > > On Thu, 2008-04-24 at 10:02 +0200, alebu wrote: > > With 1.3.1-RC2 situation is the same... :( > > > > On Thu, Apr 24, 2008 at 8:53 AM, alebu <[EMAIL PROTECTED]> > wrote: > > Hmm, don't know if that what you need (based on > axis2c-1.3.0 > > code): > > > > Program terminated with signal 11, Segmentation > fault. > > #0 0x746163696c707061 in ?? () > > (gdb) backtrace > > #0 0x746163696c707061 in ?? () > > #1 0x00002b960f68a0db in > axis2_msg_recv_make_new_svc_obj > > (msg_recv=<value optimized out>, env=0x676310, > msg_ctx=<value > > optimized out>) > > at msg_recv.c:166 > > #2 0x00002b960f68a579 in > > > axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync > > (msg_recv=0x674650, env=0x676310, msg_ctx=0x676ff0, > > new_msg_ctx=0x6829b0) at > raw_xml_in_out_msg_recv.c:99 > > #3 0x00002b960f68a2b1 in > axis2_msg_recv_receive_impl > > (msg_recv=0x674650, env=0x676310, msg_ctx=0x676ff0, > > callback_recv_param=<value optimized out>) at > > msg_recv.c:319 > > #4 0x00002b960f681a75 in axis2_engine_receive > > (engine=0x6803c0, env=0x676310, msg_ctx=0x676ff0) at > > engine.c:297 > > #5 0x00002b960f557542 in > > axis2_http_transport_utils_process_http_post_request > > (env=0x676310, msg_ctx=0x676ff0, > > in_stream=<value optimized out>, > out_stream=<value > > optimized out>, content_type=0x676530 > > "text/xml;charset=UTF-8", > > content_length=<value optimized out>, > > soap_action_header=0x677650, > > request_uri=0x6773c0 > > "http://127.0.0.1:9090/axis2/services/uniservice") > at > > http_transport_utils.c:583 > > #6 0x00002b960f55587e in > axis2_http_worker_process_request > > (http_worker=0x676190, env=0x676310, > svr_conn=0x676350, > > simple_request=0x676490) at http_worker.c:400 > > #7 0x00002b960f8cd26e in > axis2_svr_thread_worker_func > > (thd=0x676160, data=0x674c20) at > http_svr_thread.c:254 > > #8 0x00002b960faf6143 in start_thread () > > from /lib64/libpthread.so.0 > > #9 0x00002b960fedf74d in clone () > from /lib64/libc.so.6 > > #10 0x0000000000000000 in ?? () > > ------------ > > I will try the same with 1.3.1-RC2 now > > > > > > > > On Wed, Apr 23, 2008 at 10:09 AM, Manjula Peiris > > <[EMAIL PROTECTED]> wrote: > > Hi alebu, > > > > If it segfaults can you send us the gdb > backtrace ? > > BTW, another RC of > > 1.3.1 will be available soon. > > > > Thanks, > > -Manjula. > > > > > > > > On Wed, 2008-04-23 at 09:55 +0200, alebu > wrote: > > > Link to 1.3.1 you gave is broken for me. > > > Now I got slightly different problem. > > > After compiling using g++ for compiler and > linker > > (probably i was > > > using gcc/g++ earlier and thats was the > problem) > > > I simply have segmentaion fault before any > of my > > custom code is > > > executed. First row of generated with > WSDL2C invoke > > > method was logging function and it is not > executed. > > So, as I > > > understand, problem occurs somewhere > before invoke > > call. > > > Compiling the same code with the same > parameters but > > using gcc works > > > fine. I should mention that code in both > cases is > > > C code. All declarations are covered with > > > #ifdef __cplusplus > > > extern "C" { > > > #endif > > > //code > > > #ifdef __cplusplus > > > } > > > #endif > > > In axis2c logs last LIVE line is: > > > engine.c(670) > End:axis2_engine_invoke_phases > > > engine.c(648) > Start:axis2_engine_invoke_phases > > > engine.c(670) > End:axis2_engine_invoke_phases > > > class_loader.c(140) Object loaded > successfully > > > ... and no any error messages > > > > > > Any ideas? I could try the same with > axis2c 1.3.1 > > but I need a link to > > > it (on website only 1.3.0 is available) > > > Compiler options are (fragment from > Eclipse/C log): > > > Invoking: GCC C Compiler > > > g++ > -I/opt/axis2c-1.3.0/include/axis2-1.3.0 -O0 -g3 > > -Wall -c > > > -fmessage-length=0 -fPIC -MMD -MP > > -MF"src/adb_field_type.d" > > > -MT"src/adb_field_type.d" > -o"src/adb_field_type.o" > > > > > > And linking log part is: > > > Invoking: GCC C Linker > > > g++ -L/opt/axis2c-1.3.0/lib > > -L/home/BEA/tuxedo9.1/lib -shared > > > -o"libmyservice.so" > > > ./src/adb_field_type.o ./src/adb_serve.o ./src/adb_serveResponse.o > ./src/adb_serve_req_type.o ./src/adb_serve_resp_type.o > ./src/axis2_skel_uniservice.o ./src/axis2_svc_skel_uniservice.o -ldl -lbuft > -lfml -lfml32 -lengine -ltux -lpthread -laxutil -laxis2_axiom -laxis2_engine > -laxis2_parser -laxis2_http_sender -laxis2_http_receiver -laxis2_libxml2 > > > > > > Some additional libraries relative to BEA > Tuxedo are > > included, but I > > > don't think that they are the problem. > > > > > > > > > On Mon, Apr 14, 2008 at 4:08 PM, Samisa > Abeysinghe > > <[EMAIL PROTECTED]> > > > wrote: > > > What are the compiler options you > used when > > compiling the > > > service? > > > > > > We have added the dlerror to the > log in > > 1.3.1. The RC is > > > available, can you try with that? > > > > > > Samisa... > > > > > > alebu wrote: > > > > > > Hi list. > > > I have such a situation: > > > I have some web-service > which was > > generated from WSDL > > > using WSDL2C utility. > > > Later I decided to write > part of > > this web-service with > > > C++. Before functions that > uses > > > C++ code I put: > > > #ifdef __cplusplus > > > extern "C" > > > #endif > > > Then I tried to compile > using g++. > > During compilation > > > some errors were found, > but > > > all of them was about > incorrect > > conversion from void* > > > into axis2 types. > > > When I fixed them (I hope) > but when > > I call this > > > web-service I got axis > error: > > > ... > > > > > <faultcode>soapenv:Server</faultcode> > > > > <faultstring>Failed in > > creating > > > DLL</faultstring> > > > ... > > > In axis2.log only one > message was > > interesting for me: > > > > raw_xml_in_out_msg_recv.c(115) Impl > > object for service > > > 'myService' not set in > message > > receiver. 100 :: Failed > > > in creating DLL > > > > > > I understand that it > probably was'nt > > very wise to > > > compile .c files using g++ > but, > > compilation was > > > sucessful, so I wonder > > > where possible problem can > be. > > > Is it possible at all to > compile > > axis2/C web serice > > > from C++ sources using C++ > > possibilities? > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > No virus found in this > incoming > > message. > > > Checked by AVG. Version: > 7.5.519 / > > Virus Database: > > > 269.22.13/1376 - Release > Date: > > 4/13/2008 1:45 PM > > > > > > > > > > > > -- > > > Samisa Abeysinghe Director, > Engineering; > > WSO2 Inc. > > > > > > http://www.wso2.com/ - "The Open > Source SOA > > Company" > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
