The delay for the public cvs access appears to be normal for sf.net On the Content element, looking at Release 5 of the document, the Content element does not seem to have any default setting. Unless I am missing something.
P. On Feb 24, 2006, at 14:09, Dziugas Baltrunas wrote: > Hi, > > well, Content element is not mandatory according to the specs and some > MMSC assume that the next MIME part is the right one. > > Thanks for fixing, but did you really commit changes to cvs? Or sf.net > is again too slow to sync with the changes. In cvsweb no fresh commits > are visible as well. > > On 2/24/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote: >> Hi, >> >> You are missing the 'Content' element which tells the SOAP >> recipient what part of the HTTP body is the message body. >> Nonetheless the mms_msg module should have done better checking for >> NULLs. I've done some work in this regard and updated CVS. >> >> Thanks again >> P. >> >> On Feb 23, 2006, at 20:20, Dziugas Baltrunas wrote: >> >>> Hi list, >>> >>> I'm using CVS head and was trying to test MM7 interface but >>> unfortunately got a segmentation fault. Here are the last lines >>> mmsproxy spawns and the gdb back trace: >>> >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=TransactionID, >>> v=ID_1234! >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=MessageType, >>> v=SubmitReq! >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=MM7Version, >>> v=5.3.0! >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=VASPID, v=test! >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=To, v=+ >>> 370xxxxxxxx/TYPE=PLMN! >>> 2006-02-23 19:03:41 [8279] [5] INFO: parse.soap, h=Subject, v=MMS >>> testas! >>> 2006-02-23 19:03:41 [8279] [5] DEBUG: --> Enterred mm7dispatch >>> interface, mreq=Ok mtype = SubmitReq <-- >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread -1249956944 (LWP 8287)] >>> 0x0806788a in mime_entity_duplicate (m=0x0) at mms_util.c:863 >>> 863 mx->headers = http_header_duplicate(m->headers); >>> (gdb) bt >>> #0 0x0806788a in mime_entity_duplicate (m=0x0) at mms_util.c:863 >>> #1 0x0805cfde in mms_frommime (mime=0x0) at mms_msg.c:1285 >>> #2 0x080696ee in mm7_soap_to_mmsmsg (m=0x906e9a0, >>> from=0x9070298) at >>> mms_mm7soap.c:733 >>> #3 0x08056f4a in mm7soap_dispatch (h=0x9070b98) at mmsproxy.c:1600 >>> #4 0x08075900 in new_thread () >>> #5 0x00672341 in start_thread () from /lib/tls/libpthread.so.0 >>> #6 0x0058b6fe in clone () from /lib/tls/libc.so.6 >>> >>> >>> The whole dump is attached. >>> >>> P.S. I'm resending this message with a zipped dump file. Isn't 40 KB >>> too low limit for a single message? (I got Message body is too big: >>> 42545 bytes with a limit of 40 KB) >>> >>> -- >>> Dziugas >>> <mm7_segfault.zip> >>> _______________________________________________ >>> Devel mailing list >>> Devel@mbuni.org >>> http://mbuni.org/mailman/listinfo/devel_mbuni.org >> >> ----------------------------------------------- >> Trek the Rwenzori's. Or just see them online - http:// >> www.rwenzori.com/gallery.htm >> >> >> _______________________________________________ >> Devel mailing list >> Devel@mbuni.org >> http://mbuni.org/mailman/listinfo/devel_mbuni.org >> > > > -- > Dziugas > > _______________________________________________ > Devel mailing list > Devel@mbuni.org > http://mbuni.org/mailman/listinfo/devel_mbuni.org ----------------------------------------------- Trek the Rwenzori's. Or just see them online - http:// www.rwenzori.com/gallery.htm _______________________________________________ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
