Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak due to that the function ithread_detach is
not called for finished worker threads in ThreadPool.c.
==21137== 2,176 bytes in 8 blocks are possibly lost in loss record 5 of 5
==21137== at 0x4C20F3F: calloc (vg_replace_malloc.c:279)
==21137== by 0x4010F58: _dl_allocate_tls (in /lib/ld-2.6.1.so)
==21137== by 0x544BA92: pthread_create@@GLIBC_2.2.5 (in
/lib/libpthread-2.6.1.so)
==21137== by 0x5F94592: CreateWorker (ThreadPool.c:639)
==21137== by 0x5F95079: ThreadPoolInit (ThreadPool.c:784)
I'm using libupnp 1.6.6
For more info on pthread_detach, see:
http://gelorakan.wordpress.com/2007/11/26/pthead_create-valgrind-memory-lea
k-solved/
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@520 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted: Ulrik ( ulsv_enea ) - 2008-12-05 08:24
Valgrind reports a memory leak function in AdvertiseAndReply
(ssdp/ssdp_server.c) in libupnp 1.6.6
There are continue statements in many places in AdvertiseAndReply. In some
of those error handling cases the variable nodelist is not free'ed before
continuing to the next iteration. The next iteration will take care of
free'ing the nodelist from the previous iteration in most cases, but not
when breaking out of the for loop after the last element.
I belive this memory leak can be solved by makeing sure that the rows
ixmlNodeList_free( nodeList );
nodeList = NULL;
are always executed, also in the beginning of the last iteration when we
found out that there are not more elements.
==29110== at 0x4C21C16: malloc (vg_replace_malloc.c:149)
==29110== by 0x5D8DE0E: ixmlNodeList_addToNodeList (nodeList.c:106)
==29110== by 0x5D8B7E2: ixmlNode_getElementsByTagNameRecursive
(node.c:1438)
==29110== by 0x5D8E587: ixmlElement_getElementsByTagName
(element.c:491)
==29110== by 0x5B6C0F1: AdvertiseAndReply (ssdp_server.c:201)
==29110== by 0x5B7AB74: UpnpSendAdvertisement (upnpapi.c:1495)
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@518 119443c7-1b9e-41f8-b6fc-b9c35fce742c
libupnp and multi-flows scenario patch
Submited by Carlo Parata from STMicroelectronics.
Hi Roberto and Nektarios,
after an analysis of the problem of libupnp with a multi-flows scenario, I
noticed that the only cause of the freezed system is the ThreadPool
management. There are not mutex problems. In practise, if all threads in the
thread pool are busy executing jobs, a new worker thread should be created if
a job is scheduled (I inspired to tombupnp library). So I solved the problem
with a little patch in threadutil library that you can find attached in this
e-mail. I hope to have helped you.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@515 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2964973 ] install: will not overwrite just-created
...blah... with...
Submitted: Nick Leverton ( leveret ) - 2010-03-07 05:18
Full error:
/usr/bin/install: will not overwrite just-created
`/tmp/buildd/libupnp-1.6.6/debian/tmp/usr/share/doc/libupnp3-dev/examples/s
ample_util.c' with `common/sample_util.c'
This seems to be from Automake 1.11 which doesn't like having duplicate
files in a Makefile.am. Patch attached, kindly provided by Stefan Potyra
for Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543068)
This fix will be needed for both 1.6.x and 1.8.x branches.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@511 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: zephyrus ( zephyrus00jp )
Obs by Marcelo: The issue with linking with -lsocket -lnsl -lrt is not
covered in this changeset beacuse I don't have solaris to test. I will
need some help from zephyrus in this regard. The issue will be addressed
in a future changeset.
Compilation for solaris
I have used gcc3.x and gcc4.x under solaris 10 for x86 / 64 bits.
A couple of Source file fixes were necessary for successful compilation
and runtime behavior.
threadutil/src/ThreadPool.c
POSIX
sched_setschduler() returns non-negative value for success.
Without the fix, UpnpInit() fails immediately.
upnpp/src/api/upnpai.c
There is a typo of a macro name "__sun" in one of the
CPP conditional.
Without the fix, the compilation aborts due to unknown constant
in socket ioctl call.
A few structs and an array is not properly initialized.
Well, I think it may be safe as is, but when I checked it
using purify evaluation version, it was reported that
uninitizlied iszBuffer may cause read of uninitialized memory.
So play it safe.
Configure issue.
This has to be more of a configure magic.
To link a program successfully using network, we need
-lsocket and -lnsl library specifications on the link line.
We also need -lrt for programs that use thread scheduling features.
The sample program under upnp/sample requires
-lsocket -lnsl -lrt
for successful linking.
I added -lsocket -lnsl -lrt to Makefile.in.
configure probably needs to take care of these.
I don't know much about configure, automake, etc., so
I am just raising a flag here.
TIA
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@505 119443c7-1b9e-41f8-b6fc-b9c35fce742c
stopping at the first lis
Submitted By: zephyrus ( zephyrus00jp )
Internet Gateway Device description contains nested serviceList (rootdevice
-> servicelist, subdevice
and subdevice has the lower-level serviceList, etc..)
Unfrotunately, the sample code sample_util.c used by tv_device sample,
etc.
has a code that looks for only the first top-level serviceList.
This results in the failure to read all the services of an IGD xml
description.
Attached patch modifies this behavior and looks for the service by
visiting all the serviceList in xml document in turn.
With the modified patch (ad additional modification), I could
simulate an IGD device and created a modified control program for that.
Patch against 1.6.6
TIA.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@502 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* SF Patch Tracker [ 2970872 ] Update ErrorMessages for latest return
code list
Submitted By: Nick Leverton ( leveret )
ErrorMessage[] in upnptools.c has got a bit out of sync, the attached
patch (generated from grep 'define UPNP_E_') should bring it up to date.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@496 119443c7-1b9e-41f8-b6fc-b9c35fce742c
(void) argument list.
* SF Patch Tracker [ 2857611 ] Declare a few functions to have proper
(void) argument list.
Submitted By: zephyrus ( zephyrus00jp )
In a publicly installed headers, a few functions are declared without any
arguments at all, a la "()".
When I used gcc's -Wimplict and -Wstrict-prototypes to check for the
mismatch of
function prototype declarations and their usage in my own program,
some headers from libupnp-1.6.6 produced warnings.
They are not strictly bugs, but pretty much annoying. This is 2009, and
almost all the important compilers
understand ISO-C.
So the offending functions are declared as "(void") to show that they have
no arguments at all.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@494 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Patch Tracker [ 2546532 ] Missing carriage return between
SOAPACTION and User-Agent headers.
There is something going wrong in soap_ctrlpt.c at line 931 (based on
version 1.6.6 release).
The http_Makemessage call looks as follows:
if (http_MakeMessage(
&request, 1, 1,
"Q" "sbc" "N" "s" "s" "Ucc" "sss",
SOAPMETHOD_POST, path.buf, path.length,
"HOST: ", host.buf, host.length,
content_length,
ContentTypeHeader,
"SOAPACTION:
\"urn:schemas-upnp-org:control-1-0#QueryStateVariable\"",
xml_start, var_name, xml_end ) != 0 ) {
return UPNP_E_OUTOF_MEMORY;
}
This will result in the SOAPACTION header to be immediately followed by the
User-Agent header, while a cr-lf should separate the two. I propose to fix
this by changing the second "s" to "sc" to force the addition of a cr-lf
after the SOAPACTION. This looks consistent to the other Makemessage calls.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@487 119443c7-1b9e-41f8-b6fc-b9c35fce742c
395: Bob Ciora's patch for lazy UpnpAcceptSubscription().
434: Fixed a buffer overflow due to a bug in the calculation of the
CONTENT-TYPE header line size, the length was beeing calculated with
the wrong string, there was a missing colon.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@461 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Nick Leverton - leveret
Gnu/KFreeBSD is one of the Debian architectures, it includes a FreeBSD
kernel with GNU userspace (glibc etc). The Gnu/KfreeBSD developers
provided the attached patch to test the appropriate #define and allow pupnp
to build in their environment, and asked me to forward it to you.
Since the test is a simple check for defined(__GLIBC__), this would
presumably also help with other ports of GNU libc to non-Linux kernels.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@458 119443c7-1b9e-41f8-b6fc-b9c35fce742c
