SF Bug Tracker [ 3022490 ] String declaration fix for patch applied in 3007407
Hello,
When my patch for tracker ID 3007407 was accepted, the definition of the
serviceList string was changed from
#define SERVICELIST_STR "serviceList"
to
static const char *SERVICELIST_STR = "serviceList";
During internal code review of the final patch, it was pointed out that
sizeof(SERVICELIST_STR) == 4 since SERVICELIST_STR is now declared as
a pointer instead of an array.
If you wish to use a variable instead of a define, I suggest the
following instead:
static const char SERVICELIST_STR[] = "serviceList";
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@557 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Backport of svn revision 552:
SF Bug Tracker [ 3007407 ] Service traversal issue in AdvertiseAndReply()
Submitted: Chuck Thomason ( cyt4 ) - 2010-05-26 15:07:39 UTC
When the UPnP server is started, one alive message is broadcast for each
service in each device. It appears that libupnp's implementation of the
alive message generation does not correctly navigate the XML description
document when locating the services. This can result in the wrong UDN
being used in the alive message sent for a service.
In my specific case (see attached XML), the root EchoSTB device contains
no services, but its embedded MediaServer device contains 2 services.
When the existing libupnp code traverses the EchoSTB device in the XML,
it searches the global list of serviceLists within the document instead
of searching for a serviceList that is its direct child node. The
ContentDirectory and ConnectionManager services are then announced with
the UDN of EchoSTB1 (the root device) instead of with the UDN of
MediaServer, which is actually their parent device.
I discovered this behavior using libupnp-1.6.6. I have generated a patch
against branch-1.6.x that corrects the XML navigation such that all
services are traversed from their parent device, which results in the
correct UDN being sent in the alive message for each service. I built
from branch-1.6.x without this patch, tested, and confirmed that the
issue still exists as I observed it in libupnp-1.6.6. I then built
from branch-1.6.x with this patch, tested, and confirmed that the
issue was resolved.
Thanks,
Chuck Thomason
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@553 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted: viallard anthony ( homer242 )
When trying to use reuseaddr option in miniserver/miniserver.c, there
isn't a affectation of the port chosen (serverAddr.sin_port isn't
receive listen_port variable value).
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/branches/branch-1.6.x@548 119443c7-1b9e-41f8-b6fc-b9c35fce742c
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
befor calling va_end().
- Removed all uses of the DBGONLY(x) macro. A static inline empty
function now is used and the compiler takes care of optimizing it out.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@185 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Thanks to David Maass.
* sizeof is unsigned, so %zu is more adequate than %zd.
* Using an invented printf directive PRIzu that on MSVC
expands to "lu", and on normal C99 compilers expands to "zu".
* Rewrote raw_find_str. Now it no longer uses strcasestr(), but it
transforms the first input buffer into lowercase.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@184 119443c7-1b9e-41f8-b6fc-b9c35fce742c
upnp to folder upnp/sample. Moved folder upnp/sample/tvdevice/web
to folder upnp/sample/web. This way, if someone compiles the
tarball and executes upnp_tv_device from its creation directory,
there will be no error -108 for not finding directory web.
Also changed svnignore in the process.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@183 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Glen Masgai
after an UpnpSendActionAsync() for example, i get UPNP_E_OUTOF_MEMORY
in the callback using 1.4.4 on a x86_64 system. This happens in
http_MakeMessage(), which in some cases get called with wrong types
(int instead of size_t) in combination with format "b" and "Q".
The attached patch should fix this.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@166 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Timothy Redaelli - drittz
I made some patches to make it compile under FreeBSD using
gethostbyaddr_r when supported.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@165 119443c7-1b9e-41f8-b6fc-b9c35fce742c
It would loop forever.
- Also strcasestr() is a gnu extension, we need the proper define so that
the prototype is accessable.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@163 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Michael Andersen - miwer
Issue was found to be related to sizeof (size_t) != sizeof (int)
on AMD64 systems. Emil Ljungdahl's AMD64 patch has been applied along
with some other fixes. Original user report follows:
When I run upnpd I get the above mentioned error (UPNP_E_OUTOF_MEMORY).
I've tried with 1.4.1 and 1.4.2-RC3, it's the same. I don't understand why,
because I have plenty of RAM, and I even tried closing some applications,
but it didn't help.
$ upnpd eth1 br0
The following is logged in the /var/log/messages:
Feb 6 01:33:47 server upnpd[6933]: Error registering the root device with
descDocUrl: http://192.168.0.1:49152/gatedesc.xml
Feb 6 01:33:47 server upnpd[6933]: UpnpRegisterRootDevice returned -104
I tried enabling debugging and it looks like it cannot allocate memory
through the membuffer_append function. It's wierd because it's only a few
bytes.
Please note, that I enabled some extra debugging lines that were commented,
in order to get more information. See attached files.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@154 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jon Foster - jongfoster
This patch gives basic support for building under Cygwin - it compiles,
links, and a simple UPnP device application can initialise. I'm not sure
if it actually works yet, but this is definitely a step in the right
direction.
Patch is against the 1.4.1 release. Changes are:
* threadutil/inc/ithread.h: Fix the ithread mutex support to use
documented, portable APIs (if present) rather than the Non-Portable (_NP)
ones it uses now. This is required because Cygwin implements only the
portable API.
* threadutil/src/ThreadPool.c: Fake SetPolicyType() to do nothing on Cygwin
because otherwise it fails. Should probably investigate why it fails and
add a proper implementation later.
* upnp/src/api/upnpapi.c: On Cygwin, zero out the GlobalHndMutex structure
before initialising it. Without this, the initialisation fails. This
appears to be a bug in Cygwin.
* upnp/src/genlib/net/uri/uri.c: Use gethostbyname() on Cygwin.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@151 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Jonathan - no_dice
Summary: This patch hopefully fixes the remaining types and related
code to enable files >= 2 GiB to be streamed. Jonathan claims to have
tested this with a patched version of ushare-0.9.8 and a D-Link DSM-520.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@121 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
This patch fixes two problems:
* Specify the IP address for the interface when we do setsockopt IP_ADD_MEMBERSHIP. This makes it possible to run when no default router has been configured.
* Explicitly set the multicast interface through setsockopt IP_MULTICAST_IF. Avoids socket error -207 in some cases.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@119 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
Incremented the libray versions and included some comments in the file
configure.ac so that we do not bump the library version excessively,
only the necessary numbers on the next release.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@115 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By:
Fredrik Svensson - svefredrik
A few modifications to the patch were made:
1) Do not introduce new CRLF's where there were none.
2) Applied the same original idea to two other palces in soap_ctrlpt.c.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@114 119443c7-1b9e-41f8-b6fc-b9c35fce742c
in rev.79: largefile patch added.
http_MakeMessage() has a worst than brain damaged "printf" like interface.
In rev.79, the "N" format parameter must be an off_t. Every call of this
function with an "N" format parameter and an int passed on the stack
would fail terribly.
Not every place I touched had a bug, but to review the format and keep my
sanity, I had to format it properly.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@96 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[submitted-by] Erik Johansson - erijo
[patched-by] Erik Johansson - erijo
The SOAP HTTP message that's generated on upnp errors
is missing a \r\n\ between header and body.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@95 119443c7-1b9e-41f8-b6fc-b9c35fce742c
strlen returns size_t which is long or int depending on the platform.
We use %ld in printf and cast the return value to long.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@71 119443c7-1b9e-41f8-b6fc-b9c35fce742c
