Hi,
I had found some bugs about memory leak on libupnp-1.6.18.
It may lead to memory leak when calling ThreadPoolAdd() or
ThreadPoolAddPersistent() which does not return 0.
See the attachment for patch.
(cherry picked from commit 8e3a71905b)
Conflicts:
upnp/src/ssdp/ssdp_ctrlpt.c
In soap_ctrlpt.c, in function get_response_value:
upnp_error_code is checked to see if it is less than 400 because that
would indicate a SOAP error code.
However it should be checked to see if it is greater than 400.
(cherry picked from commit 7b1aa4c9e3)
Dear libupnp-devels,
when POST'ing to the simple web server in libupnp, the application crashes.
This is caused by a missing "..." argument in webserver.c:1533.
Seems it has been there for a long time ... 1.6.9 and 1.6.18 have it.
webserver.c:1533 calls http_MakeMessage
/* Send response. */
http_MakeMessage(&headers, 1, 1,
"RTLSXcCc",
ret, "text/html", X_USER_AGENT);
The format parameter RTLSXcCc needs four arguments -
R - response code - ret,
T- content type - text/html,
L - struct SendInstruction * - NOT PRESENT
X - user agent - X_USER_AGENT
This results in a crash.
Changing to
http_MakeMessage(&headers, 1, 1,
"RTLSXcCc",
ret, "text/html", &RespInstr, X_USER_AGENT);
solves the situation.
Yours,
Sebastian Brandt
(cherry picked from commit 25c27b8af7)
This patch fixes a bug in non blocking connect call where the sock
option length for SO_ERROR was passed as 0 instead of sizeof(int).
(cherry picked from commit 6db2271ac3)
Submitted: zephyrus ( zephyrus00jp ) - 2012-03-07 02:31:14 PST
Details: a function is declared as
EXPORT_SPEC IXML_Document *ixmlDocument_createDocument();
This should read as follows in order to suppress strict prototype checking by GCC.
EXPORT_SPEC IXML_Document *ixmlDocument_createDocument(void);
(cherry picked from commit 9965f02727)
Details:
Hello. I trying compile libupnp-1.6.10 on the Fedora 14 MinGW
Environment and get many errors. I create patch to fix it. With this
patch i can get static library. This patch is very raw.
Submitted: Ivan Romanov (ivanromanov) - 2010-12-16 23:29:19 UTC
(cherry picked from commit b2a88aa70b)
SF Bug Tracker - ID: 3104521
Submitted: OBATA Akio ( obache ) - 2010-11-07 07:03:44 BRST
In configure.ac
AC_CHECK_FUNCS(ftime,, [AC_CHECK_LIB(compat, ftime)])
But since version 1.6.3, ftime(3) is not used, so it should be
removed, or introduce unwanted linkage with -lcompat.
(cherry picked from commit 852c301c5c)
By "Carl Benson" <carl.benson@windriver.com>:
I had to do some modifications myself though, because the Android
build system insists on having a file named "util.h" taking precedence
in its include path, libupnp gets confused because of the same filename
in upnp/src/inc/util.h
(hand cherry picked from commit 8e846368e0)
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/trunk@552 119443c7-1b9e-41f8-b6fc-b9c35fce742c
[svn] SF Bug Tracker [ 2995758 ] libupnp 1.6.6, wrong bind when reuseaddr is 1.
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/trunk@549 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/trunk@457 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By Luke Kim - nereusuj
Version 1.6.5 cannot be compiled because of some changes in 1.6.3.
MSVC does not support stdint.h, gettimeofday(), sys/param.h, const int
variables in array size and Windows does not define _WINDOWS_ but define
_WINDOWS.
* MSVC does not understand "const int"'s as declarators of array
dimensions, we must use #define'd constants.
* Use WIN32 instead of _WINDOWS_ or _WINDOWS.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@331 119443c7-1b9e-41f8-b6fc-b9c35fce742c
Submitted By: Hartmut Holzgraefe - hholzgra
typo in docs comment ACCAPTED instead of ACCEPTED in
@name UPNP_E_UNSUBSCRIBE_UNACCAPTED [-302]
Also, the documentation file name was mispelled and was corrected in
the Makefile.am.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@287 119443c7-1b9e-41f8-b6fc-b9c35fce742c
rwlock. HandleLock() is mapped to HandleWriteLock() while all other
instances have not been checked. One instance in AdvertiseAndReply()
has been changed to HandleReadLock(). Thanks to Alex (afaucher) for the
bug report and suggestions.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@233 119443c7-1b9e-41f8-b6fc-b9c35fce742c
SF Bug Tracker [ 1686420 ] Modifications for MacOSX.
Some of the proposed changes were already done by Rene Hexel's patch.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@213 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
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: 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: 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
