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
Generating an rpm now is as easy as:
$ rpmbuild -ta libupnp-1.4.1.tar.gz
- Added Eric's name to the THANKS file and sorted it in
ascending first name order.
git-svn-id: https://pupnp.svn.sourceforge.net/svnroot/pupnp/trunk@50 119443c7-1b9e-41f8-b6fc-b9c35fce742c
