2 - Backport of svn revision 527:
* Added API to ithread, created the following functions:
- int ithread_initialize_library(void);
- int ithread_cleanup_library(void);
- int ithread_initialize_thread(void);
- int ithread_cleanup_thread(void);
* SF Bug Tracker [ 2876374 ] Access Violation when compiling with Visual Studio 2008
Submitted: Stulle ( stulleamgym ) - 2009-10-10 19:05
Hi,
I am one of the devs of the MorphXT project and I use this lib in some
other of my projects, too. When I tried to upgrade the lib earlier for one
of my projects I had to realise that something did not work at first and
while most of the things were reasonably ease to be fixed. Now, the last
thing I encountered was not so easy to fix and I am uncertain if my fix is
any good so I'll just post it here and wait for some comments.
The problem was that I got an Access Violation when calling "UpnpInit". It
would call "ithread_rwlock_init(&GlobalHndRWLock, NULL)" which eventually
led to calling "pthread_cond_init" and I got the error notice at
"EnterCriticalSection (&ptw32_cond_list_lock);". It appeared that
"ptw32_cond_list_lock" was NULL. Now, I found two ways to fix this. Firstly
moving the whole block after at least one of the "ThreadPoolInit" calls
will fix the issue. Secondly, you could add:
#ifdef WIN32
#ifdef PTW32_STATIC_LIB
// to get the following working we need this... is it a good patch or
not... I do not know!
pthread_win32_process_attach_np();
#endif
#endif
right before "ithread_rwlock_init(&GlobalHndRWLock, NULL)".
Just so you know, I am using libupnp 1.6.6 and libpthreads 2.8.0 and both
are linked static into the binaries. I am currently using Visual Studio
2008 for development with Windows being the target OS. Any comment at your
end?
Regards, Stulle
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@529 119443c7-1b9e-41f8-b6fc-b9c35fce742c
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
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
[pupnp-devel] NetBSD & Mac OS X packages and patches
Okay, I found a couple more things. I have attached a patch file
against the trunk (version 206) that make the repository code compile
and run on both Mac OS X and NetBSD.
This fixes the following issues:
upnp/src/api/upnpapi.c: SIOCGIFCONF didn't work properly, use
getifaddrs() instead (on BSD systems).
threadutil/src/ThreadPool.c: priorities only work if
_POSIX_PRIORITY_SCHEDULING is defined (and greater than 0).
threadutil/src/LinkedList.c and threadutil/src/iasnprintf.c: use
stdlib.h instead of malloc.h on all BSD systems (not just FreeBSD).
This is important, because malloc.h does not exist on Darwin/Mac OS X.
Cheers
,
Rene
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@207 119443c7-1b9e-41f8-b6fc-b9c35fce742c
ax_cflags_warn_all.m4, m4/ax_cflags_warn_all_ansi.m4,
m4/type_socklen_t.m4.
* Fixed an issue with the instalation of the file upnpdebug.h. Since
the last modifications that removed the macro DEBUV_ONLY, this file
must be installed even on a non-debug build.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@204 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Bob Ciora
The field DestAddr of the structure Upnp_Discovery is now a full
SOCKADDRIN instead of a pointer to SOCKADDRIN. Commented code sugests
that in a previous moment, the function ssdp_handle_ctrlpt_msg() did
not use a postponed thread to call ctrlpt_callback(). Now the code
uses a thread, and most probably the original data would get lost and
the pointer would point to an invalid memory region. This fix caused
an interface change in the library and the minor library version was
bumped. Also, the libtool library numbers were changed accordingly.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@203 119443c7-1b9e-41f8-b6fc-b9c35fce742c
defines. These were just aliases, no reason to keep them.
* Changed the comments of the include files that expose the UPnP API
to use only C89 comments and no C99 comments.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@198 119443c7-1b9e-41f8-b6fc-b9c35fce742c
* Enable both device and control point in the same application. Resolve
deadlock in the SSDP processing threads.
* Fix Threadpool expansion condition.
Thanks to Siva Chandran P. for the original patch.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@194 119443c7-1b9e-41f8-b6fc-b9c35fce742c
compatible with WinXP/IE control point. 'in' arguments must appear before
'out' arguments in argument list.
Thanks to Martin Tremblay for pointing out the solution originally
provided by MORIOKA Yasuhiro.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@193 119443c7-1b9e-41f8-b6fc-b9c35fce742c
