axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose M Medina V <jose_med...@wesamconsulting.com>
Subject Re: Problem with Ubuntu
Date Tue, 22 Sep 2009 01:17:51 GMT
Well here an update of the problem

I could reproduce the error in a Centos 5 (64 bits) installation, so I  
think the problem is something related with 64 bit installation and  
not with the deferent operating system.

As you suggest, I install the valgrind utilities and I run the test  
with the following command
[root@linux-desa logs]# valgrind /usr/sbin/httpd -X -d /etc/httpd
==23257== Memcheck, a memory error detector
==23257== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et  
al.
==23257== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright  
info
==23257== Command: /usr/sbin/httpd -X -d /etc/httpd
==23257==
==23257== Syscall param semctl(IPC_SET, arg.buf) points to  
uninitialised byte(s)
==23257==    at 0x69AA4CA: semctl (in /lib64/libc-2.5.so)
==23257==    by 0x144E70: unixd_set_proc_mutex_perms (in /usr/sbin/ 
httpd)
==23257==    by 0x144E98: unixd_set_global_mutex_perms (in /usr/sbin/ 
httpd)
==23257==    by 0xE2AB6FA: ??? (in /usr/lib64/httpd/modules/ 
mod_rewrite.so)
==23257==    by 0x13186B: ap_run_post_config (in /usr/sbin/httpd)
==23257==    by 0x11ECD2: main (in /usr/sbin/httpd)
==23257==  Address 0x7ff000640 is on thread 1's stack
==23257==
==23257== Syscall param semctl(IPC_SET, arg.buf) points to  
uninitialised byte(s)
==23257==    at 0x69AA4CA: semctl (in /lib64/libc-2.5.so)
==23257==    by 0x144E70: unixd_set_proc_mutex_perms (in /usr/sbin/ 
httpd)
==23257==    by 0x144E98: unixd_set_global_mutex_perms (in /usr/sbin/ 
httpd)
==23257==    by 0xAE06B0D: ??? (in /usr/lib64/httpd/modules/mod_ldap.so)
==23257==    by 0x13186B: ap_run_post_config (in /usr/sbin/httpd)
==23257==    by 0x11EE1E: main (in /usr/sbin/httpd)
==23257==  Address 0x7ff000640 is on thread 1's stack
==23257==
==23257== Syscall param semctl(IPC_SET, arg.buf) points to  
uninitialised byte(s)
==23257==    at 0x69AA4CA: semctl (in /lib64/libc-2.5.so)
==23257==    by 0x144E70: unixd_set_proc_mutex_perms (in /usr/sbin/ 
httpd)
==23257==    by 0x1440D2: ap_mpm_run (in /usr/sbin/httpd)
==23257==    by 0x11EE47: main (in /usr/sbin/httpd)
==23257==  Address 0x7ff000570 is on thread 1's stack

The result was the web service work perfect, but when I start the  
apache server as normal, I still get the core in the apache log file.

Regards,


On Sep 21, 2009, at 2:44 PM, Murphey McCloy wrote:

> Just place valgrind in front of your httpd command (adding the -X  
> parameter) and run it.  For example, in my configuration I do:
>
> valgrind /usr/sbin/httpd -X -d /etc/httpd
>
> Then let it run and try to make it seg fault.  The output it  
> displays should be useful.
>
>
>
> On Sep 21, 2009, at 11:28 AM, "Jose M Medina V" <jose_medina@wesamconsulting.com 
> > wrote:
>
>> I didn’t try with this tool because I don’t know until now.
>>
>> I will read the documentation of Valgrind and run some test in the  
>> Ubuntu configuration. In the meantime, anybody has some examples  
>> for use this tool?? Any help would be appreciated.
>>
>> Regards
>>
>> On Sep 21, 2009, at 11:48 AM, Murphey McCloy wrote:
>>
>>> Hey there.  Have you tried running your application via valgrind  
>>> to see if there is memory corruption or access violations?  I  
>>> realize that it is working on CentOS but not on Ubuntu.  The fact  
>>> that it works on CentOS without crashing doesn’t mean there aren’t  
>>> memory issues, it very well may be that you have some  
>>> uninitialized value being referenced that is causing the seg  
>>> fault.  CentOS might be setting the memory to 0 by default, while  
>>> Ubuntu might not.
>>>
>>>
>>> From: Jose M Medina V [mailto:jose_medina@wesamconsulting.com]
>>> Sent: Monday, September 21, 2009 10:03 AM
>>> To: Apache AXIS C User List
>>> Subject: Fwd: Problem with Ubuntu
>>>
>>> Any update with this issue?
>>>
>>> Thanks,
>>>
>>> Begin forwarded message:
>>>
>>>
>>> From: Jose M Medina V <jose_medina@wesamconsulting.com>
>>> Date: September 17, 2009 8:26:24 AM GMT-04:30
>>> To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>
>>> Subject: Re: Problem with Ubuntu
>>>
>>> Selvaratnam thank for your response.
>>>
>>> I’m attaching all source code of the web service; the function  
>>> axis2_srvprb_agrApuesta is in web_serv_prb.c library.
>>>
>>> As additional information the command that I use to build axis2c  
>>> in Ubuntu was:
>>> ./configure --prefix=/opt/axis2c --with-apache2=/usr/include/ 
>>> apache2 \
>>>   --enable-libxml2=yes --with-apr=/usr/include/apr-1.0 --enable- 
>>> openssl=yes \
>>>   --enable-trace=yes
>>>
>>> Also the command that I use in Centos 5-32 bit (ambient where the  
>>> test run perfect) was:
>>> ./configure --prefix=/opt/axis2c --with-apache2=/usr/include/httpd  
>>> --with-apr=/usr/include/apr-1\
>>>   --enable-libxml2=yes --enable-openssl=yes \
>>>   --enable-trace=yes
>>>
>>> Again thank in advance.
>>>
>>> On Sep 16, 2009, at 10:31 PM, Selvaratnam Uthaiyashankar wrote:
>>>
>>>
>>> Hi,
>>>
>>> Can you give "axis2_srvprb_agrApuesta" method as well? I think the
>>> problem might be in the return value, because srvprb_invoke exited
>>> without any problem.
>>>
>>> Regards,
>>> Shankar
>>>
>>>
>>> On Wed, Sep 16, 2009 at 8:59 PM, Jose M Medina V
>>> <jose_medina@wesamconsulting.com> wrote:
>>>
>>> I install Axis2c into Ubuntu Server 9.04 (Linux ubuntu-server
>>> 2.6.28-15-server #49-Ubuntu SMP Tue Aug 18 20:09:37 UTC 2009 x86_64
>>> GNU/Linux) as a module for Apache 2. After that I write a web  
>>> service for
>>> test purpose and when I test the service I receive the following  
>>> error in
>>> the Apache log.
>>> “[Tue Sep 15 19:57:45 2009] [notice] child pid 3371 exit signal  
>>> Segmentation
>>> fault (11)”
>>> I start debug the program and I determine that the error was on  
>>> the return
>>> of the funtion srvprb_invoke, see the following axis2.log trace.
>>> Tue Sep 15 19:57:44 2009] [debug] web_serv_prb.c(323) [pruebaSrv]
>>> axis2_srvprb_agrApuesta:: Fin de Funcion
>>> [Tue Sep 15 19:57:44 2009] [debug] lib_skeleton.c(118) [pruebaSrv]
>>> srvprb_invoke:: Fin de Funcion
>>> The complete funtion srvprb_invoke is:
>>> axiom_node_t *AXIS2_CALL
>>> srvprb_invoke(
>>>     axis2_svc_skeleton_t * svc_skeleton,
>>>     const axutil_env_t * env,
>>>     axiom_node_t * node,
>>>     axis2_msg_ctx_t * msg_ctx)
>>> {
>>>     char  *nombreFuncion="srvprb_invoke::";
>>>     axiom_node_t *node_srvprb_agrApuesta=NULL;
>>>
>>>     AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI, "[pruebaSrv] %s Inicio  
>>> de
>>> Funcion",nombreFuncion);
>>>     /* Dependiendo de la operacion que llegue se llama a la  
>>> respectiva
>>> funcion que procesa el
>>>      * request
>>>      */
>>>     if (node)
>>>     {
>>>         if (axiom_node_get_node_type(node, env) == AXIOM_ELEMENT)
>>>         {
>>>             axiom_element_t *element = NULL;
>>>             element =
>>>                 (axiom_element_t *) axiom_node_get_data_element 
>>> (node, env);
>>>             if (element)
>>>             {
>>>                 axis2_char_t *op_name =
>>>                     axiom_element_get_localname(element, env);
>>>                 if (op_name)
>>>                 {
>>>                     if (axutil_strcmp(op_name, "inserta_apuesta")  
>>> == 0)
>>>                     {
>>>                       node_srvprb_agrApuesta =  
>>> axis2_srvprb_agrApuesta(env,
>>> node);
>>>                       if(node_srvprb_agrApuesta != NULL)
>>>                       {
>>>                         AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI,  
>>> "[pruebaSrv]
>>> %s Fin de Funcion",nombreFuncion);
>>>                         return node_srvprb_agrApuesta;
>>>                       }
>>>                       else
>>>                       {
>>>                         AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI,  
>>> "[pruebaSrv]
>>> %s Resultado en NULL",nombreFuncion);
>>>                         return NULL;
>>>                       }
>>>                     }
>>>                 }
>>>             }
>>>         }
>>>     }
>>>     AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "[pruebaSrv] %s  
>>> Parametro OM
>>> invalido en el request",nombreFuncion);
>>>     AXIS2_ERROR_SET(env->error,
>>>                      
>>> AXIS2_ERROR_SVC_SKEL_INVALID_XML_FORMAT_IN_REQUEST,
>>>                     AXIS2_FAILURE);
>>>     return NULL;
>>> }
>>> Also I run the same test into a Centos 5 installation and the test  
>>> was
>>> perfect, so I think the problem is something about ubuntu.
>>> Could anyone help me with this problem? What can I revise?
>>> Thanks in advance
>>> ------------------------------------------------------------
>>> José M. Medina V.
>>> Wesam Consulting
>>> jose_medina@wesamconsulting.com
>>> Mobile: +58(416)613-3302 +58(414)019-0580
>>> Ofc:     +58(212)959-4155 Ext. 204
>>> BB pin: 31E562BF
>>> Caracas - Venezuela
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> S.Uthaiyashankar
>>> Software Architect
>>> WSO2 Inc.
>>> http://wso2.com/ - "The Open Source SOA Company"
>>>
>>> ------------------------------------------------------------
>>> José M. Medina V.
>>> Wesam Consulting
>>> jose_medina@wesamconsulting.com
>>> Mobile: +58(416)613-3302 +58(414)019-0580
>>> Ofc:     +58(212)959-4155 Ext. 204
>>> BB pin: 31E562BF
>>> Caracas - Venezuela
>>>
>>>
>>
>> ------------------------------------------------------------
>> José M. Medina V.
>> Wesam Consulting
>> jose_medina@wesamconsulting.com
>> Mobile: +58(416)613-3302 +58(414)019-0580
>> Ofc:     +58(212)959-4155 Ext. 204
>> BB pin: 31E562BF
>> Caracas - Venezuela
>>
>>
>>
>>
>>
>>

------------------------------------------------------------
José M. Medina V.
Wesam Consulting
jose_medina@wesamconsulting.com
Mobile: +58(416)613-3302 +58(414)019-0580
Ofc:     +58(212)959-4155 Ext. 204
BB pin: 31E562BF
Caracas - Venezuela







Mime
View raw message