I'm at a bit of a loss. A quick scan of stdsoap.h doesn't reveal any code that is obviously executing statically that could be causing your problem. The fact that you aren't seeing the printf statement before either call to soap_default_SOAP_ENV__Reason() is also disturbing, as I don't see any other places where that function gets called. That said, if there is some kind of general memory corruption issue, all bets are off in any case. It could be an error in the cross compiler or linker which is causing a completely untraceable problem. One thing you might try is #including soapC.c (and any other .c files) directly into your main .c file so that your entire application consists of a single object file rather than linking multiple object files together. I'm not sure if simply compiling them all into a single object file at the command line, without creating separate .o files, would have the same effect. It seems like an unlikely source of the problem, but I'm grasping at straws at this point. If you are familiar with the structure of the stack on your platform, there are things a skilled programmer can do to get more information than gdb is giving you by manually constructing a backtrace from the core file, but it is beyond my ability to show you what you'd need to do via an email - especially for an architecture I have no familiarity with. Sorry.
--sam On Wed, Sep 17, 2008 at 11:27 PM, James <[EMAIL PROTECTED]> wrote: > At first, thanks for your lots of advice for me. > > I compile it by normail gcc on my host system, and it can work > correctly without any error. I stick printf statements into those > functions which call soap_default_string, but I don't see any message > be displayed. I think that those function aren't be called, how could > I let those function display message? > > --- In gsoap@yahoogroups.com, "Sam Gendler" <[EMAIL PROTECTED]> wrote: >> >> I don't have a lot of advice for you. If the debugger isn't giving >> you a useful backtrace, it seems you'll need to do things a bit more >> manually. I find that scattering printf statements throughout the >> code will usually let me figure things out. Since it is dying in >> static initialization, it is possible you can figure out which call is >> happening from a static initializer by inspecting the code, otherwise, >> I'd start sticking printf statements and trying to figure out the path >> from there. Just print the value stored in the Reason object at each >> location. Probably only one printf will fire, but if they both do, >> only one will have an invalid pointer. Of the two instances, it looks >> like the second is used for processing an incoming message, so that >> seems an unlikely candidate, but the first is clearly allocating the >> object just before calling, so it implies a bug in the soap_malloc >> call or an invalid sizeof(struct SOAP_ENV__Reason); >> >> Have you tried running the exact same code on your host system rather >> than via the cross compiler? Same results or different? >> >> --sam >> >> >> On Wed, Sep 17, 2008 at 8:31 PM, James <[EMAIL PROTECTED]> wrote: >> > >> > >> > ~ # gdb tr069 core >> > GNU gdb 6.8 >> > Copyright (C) 2008 Free Software Foundation, Inc. >> > License GPLv3+: GNU GPL version 3 or later >> > <http://gnu.org/licenses/gpl.html> >> > This is free software: you are free to change and redistribute it. >> > There is NO WARRANTY, to the extent permitted by law. Type "show > copying" >> > and "show warranty" for details. >> > This GDB was configured as "mipsel-linux"... >> > Reading symbols from /lib/libc.so.0...done. >> > Loaded symbols for /lib/libc.so.0 >> > Reading symbols from /lib/ld-uClibc.so.0...done. >> > Loaded symbols for /lib/ld-uClibc.so.0 >> > >> > warning: Unable to find dynamic linker breakpoint function. >> > GDB will be unable to debug shared library initializers >> > and track explicitly loaded dynamic code. >> > Core was generated by `./tr069'. >> > Program terminated with signal 11, Segmentation fault. >> > [New process 2241]#0 0x00000018 in ?? () >> > (gdb) bt >> > #0 0x00000018 in ?? () >> > #1 0x004068d4 in soap_default_SOAP_ENV__Reason (soap=0x100085b0, >> > a=0x100060ac) at soapC.c:492 >> > #2 0x100085b0 in ?? () >> > Backtrace stopped: previous frame inner to this frame (corrupt stack?) >> > >> > Hi, >> > From the above debug message, I know soap_default_SOAP_ENV__Reason > calls >> > soap_default_string at 492 line in soapC.c. >> > >> > SOAP_FMAC3 void SOAP_FMAC4 soap_default_SOAP_ENV__Reason(struct > soap *soap, >> > struct SOAP_ENV__Reason *a) >> > { >> > (void)soap; (void)a; /* appease -Wall -Werror */ >> > soap_default_string(soap, &a->SOAP_ENV__Text); >> > } >> > >> > Then the soap_default_SOAP_ENV__Reason function call > soap_default_string. >> > >> > I trace the caller! of soap_default_SOAP_ENV__Reason in soapC.c: >> > 1) SOAP_FMAC3 void SOAP_FMAC4 soap_fault(struct soap *soap) >> > { >> > ... >> > if (soap->version == 2 && !soap->fault->SOAP_ENV__Reason) >> > { soap->fault->SOAP_ENV__Reason = (struct >> > SOAP_ENV__Reason*)soap_malloc(soap, sizeof(struct SOAP_ENV__Reason)); >> > soap_default_SOAP_ENV__Reason(soap, >> > soap->fault->SOAP_ENV__Reason); >> > } >> > } >> > >> > 2)SOAP_FMAC3 struct SOAP_ENV__Reason * SOAP_FMAC4 >> > soap_in_SOAP_ENV__Reason(struct soap *soap, const char *tag, struct >> > SOAP_ENV__Reason *a, const char *type) >> > { >> > s! hort soap_flag_SOAP_ENV__Text = 1; >> > if (soap_element_begin_in(soap, tag, 0, type)) >> > return NULL; >> > a = (struct SOAP_ENV__Reason *)soap_id_enter(soap, > soap->id, a, >> > SOAP_TYPE_SOAP_ENV__Reason, sizeof(struct SOAP_ENV__Reason), 0, > NULL, NULL, >> > NULL); >> > if (!a) >> > return NULL; >> > soap_default_SOAP_ENV__Reason(soap, a); >> > >> > But I don't know where the problem is. Could you tell me how to > trace? Thank >> > you. >> > >> > --- In gsoap@yahoogroups.com, "Sam Gendler" <sgendler@> wrote: >> >> >> >> I'd suggest requesting a backtrace (bt! command) in gdb and see > what is >> >> calling the code which is cra shing. Presumably, there is something >> >> being statically initialized in stdsoap2.h which is calling code in >> >> soapC.c. The code in question is assigning to the address pointed to >> >> by 'a' but 'a' is initialized to 0x01 in the function params. >> >> Obviously, 0x01 is an invalid address to assign into, so whatever is >> >> calling soap_default_string() is not being initialized correctly. It >> >> seems likely to be a problem with the way the runtime environment on >> >> your platform initializes variables in static code. Probably a simple >> >> fix to make sure it has a valid address - the hard part is > identifying >> >> where the fix needs to be applied. >> >> >> >> --sam >> >> >> >> >> >> On Tue, Sep 16, 2008 at 7:46 PM, James abc9250@ wrote: >> >> > Hi, >> >> > The target platform is ASUS WL-500gP and its firmware version > is DD-WRT >> >> > v23 >> >> > SP2 (09/15/06) std. My host OS is Red Hat Linux. >> >> >> > I write a program on host OS and compile it with cross-compiler >> >> > mipsel-uclibc-gcc with command [mipsel-uclibc-gcc >> >> > -I/opt/brcm/hndtools-mipsel-uclibc/include >> >> > -L/opt/brcm/hndtools-mipsel-uclibc/lib -o tr069 tr069.c]. I > move the >> >> > binary >> >> > file into target platform. I telnet to the target platform, > download >> >> > that >> >> > binary file, chmod that binary file, and execute it. It can work >> >> > correctly >> >> > (printf the "Starting..." and "Exit..." text on console screen.) >> >> > >> >> > Code: >> >> > #include <stdio.h> >> >> > #include <stdlib.h> >> >> > >> >> > >> >> > > /******************************************************************************\ >> >> > * >> >> > * Forward decls >> >> > * >> >> > >> >> > > \******************************************************************************/ >> >> > int m ain(int argc, char *argv[]) >> >> > { >> >> > printf("Starting...\n"); >> >> > >> >> > printf("Exit...\n"); >> >> > exit(0); >> >> > } >> >> > >> >> > Now I add the new code but don't change the body in main function. >> >> > Code: >> >> > #include <stdio.h> >> >> > #include <stdlib.h> >> >> > #include "stdsoap2.h" >> >> > >> >> > struct Namespace namespaces[]= >> >> > { >> >> > {"SOAP-ENV", "http://schemas.xmlsoap.org/soap/envelope/"}, >> >> > {"SOAP-ENC", "http://schemas.xmlsoap.org/soap/encoding/"}, >> >> > {"xsi", "http://www.w3.org/2001/XMLSchema-instance"}, >> >> > {"xsd", "http://www.w3.org/2001/XMLSchema"}, >> >> > {NULL, NULL} >> >> > }; >> >> > >> >> > >> >> > > /******************************************************************************\ >> >> > * >> >> > * Forward decls >> >> > * >> >> > >> >> > > \******************************************************************************/ >> >> > int main(int argc, char *argv[]) >> >> > { >> >> > printf("Starting...\n"); >> >> > >> >> > printf("Exit...\n"); >> >> > exit(0); >> >> > } >> >> > >> >> > I compile it with cross-compiler mipsel-uclibc-gcc with command >> >> > [mipsel-uclibc-gcc -g -I../.. > -I/opt/brcm/hndtools-mipsel-uclibc/include >> >> > -L. >> >> > -L/opt/brcm/hndtools-mipsel-uclibc/lib -o tr069 tr069.c soapC.c >> >> > soapClient.c >> >> > soapServer.c ../../stdsoap2.c]. >> >> > >> >> > I telnet to the target platform, download that binary file, > chmod that >> >> > binary file, and execute it. >> >> > It shows ! me [Segmentation fault (core dumped)]. Then I debug > it [gdb >> >> &g t; ./tr069]: >> >> > >> >> > ~ # gdb ./tr069 >> >> > GNU gdb 6.8 >> >> > Copyright (C) 2008 Free Software Foundation, Inc. >> >> > License GPLv3+: GNU GPL version 3 or later >> >> > <http://gnu.org/licenses/gpl.html> >> >> > This is free software: you are free to change and redistribute it. >> >> > There is NO WARRANTY, to the extent permitted by law. Type "show >> >> > copying" >> >> > and "show warranty" for details. >> >> > This GDB was configured as "mipsel-linux"... >> >> > (gdb) r >> >> > Starting program: /tmp/root/tr069 >> >> > warning: no loadable sections found in added symbol-file >> >> > /lib/ld-uClibc.so.0 >> >> > warning: Unable to find dynamic linker breakpoint function. >> >> > GDB will be unable to debug shared library initializers >> >> > and track explicitly loaded dynamic code. >> >> > warning: no loadable sections found in added symbol-file > /lib/libc.so.0> >> >> > > >> >> > Program received signal SIGSEGV, Segmentation fault. >> >> > soap_default_string (soap=0x4121c4, a=0x1) at soapC.c:1005 >> >> > 1005 } >> >> > (gdb) list >> >> > 1000 #ifdef SOAP_DEFAULT_string >> >> > 1001 *a = SOAP_DEFAULT_string; >> >> > 1002 #else >> >> > 1003 *a = (char *)0; >> >> > 1004 #endif >> >> > 1005 } >> >> > 1006 >> >> > 1007 SOAP_FMAC3 void SOAP_FMAC4 soap_serialize_string(struct > soap *soap, >> >> > char >> >> > *const*a) >> >> > >> >> > I don't why this happen. Because I don't call any other except for >> >> > printf in >> >> > main body. >> >> > Could someone give me any suggestions or guidelines to trace the >> >> > problem? >> >> > Thank you. >> >> > >> >> > >> >> >> > >> > >> > >
