Submitted: Marcelo Roberto jimenez ( mroberto ) - 2012-02-26 16:50:23 PST
src/genlib/net/http/httpparser.c: In function ‘parser_parse_requestline’:
src/genlib/net/http/httpparser.c:1319:28: warning: ‘index’ may be used uninitialized in this function
Submitted: Yoichi NAKAYAMA ( yoichi ) - 2012-02-21 07:06:35 PST
In genaSubscribe() (defined in upnp/src/gena/gena_ctrlpt.c),
ActualSID and EventURL will not be freed if ScheduleGenaAutoRenew
returns UPNP_E_SUCCESS.
This fixes the an issue introduced by the previous fix.
Submitted: Yoichi NAKAYAMA ( yoichi ) - 2012-02-21 07:06:35 PST
In genaSubscribe() (defined in upnp/src/gena/gena_ctrlpt.c),
ActualSID and EventURL will not be freed if ScheduleGenaAutoRenew
returns UPNP_E_SUCCESS.
This fixes the original issue.
(cherry picked from commit bc473d5e68c0d7248c4fffae0579f229357d04cf)
Conflicts:
upnp/src/gena/gena_ctrlpt.c
In genaSubscribe() (defined in upnp/src/gena/gena_ctrlpt.c),
ActualSID and EventURL will not be freed.
(cherry picked from commit 2940cbf94a81bdfebb2e6a61a4d2a5488050748a)
Submitted by Berend Dekens ( Berend Dekens ) - 2012-02-08 06:24:31 PST
In httpparser.c on line 1385 it says that HTTP 1.0 replies are blocked
because the UPnP verfication tool requires this.
I looked in the specs and as far as I can find, one should only be
carefull to send chunked communication to hosts supporting HTTP 1.1.
There is no requirement to support only HTTP 1.1.
The XBMC media server uses the Platinum UPnP library which replies
using HTTP/1.0 messages. As it is now, libupnp returns an error while
trying to parse the response while the response itself is completely
valid.
Is there a requirement in the UPnP 1.0 spec that I missed or is this
restriction self-imposed? And can it be lifted?
-------------------------------------------------------------------
Comment by Fabrice Fontaine:
Hide
Hi,
You're right, this modification should be removed. This version checking
was wrongly added in parser_parse_responseline function.
...
(cherry picked from commit d87c966ec5f17d5fbef1b409f426c0d70cd6231f)
Attached is a patch that resolved an issue I found with a server that
gave its device description URI without a trailing slash (e.g.
`http://127.0.0.1:5555`).
(cherry picked from commit a9c24fc7f327adefc5708e4565d15d65c49224ab)
Small bug fix on IPv6 Control Point: now CP will also send M-SEARCH on
site-scope address (FF05::C) instead of only sending M-SEARCH on
link-scope (FF02::C).
Setting IPv6 sockets with IPV6_V6ONLY flag to avoid getting IP packets
with IPv4-mapped IPv6 addresses on IPv6 sockets.
(cherry picked from commit 80a65e5f61bc16d4a27c3f82774e2039a391794f)
SF Bug tracker, ID: 3469344
Submitted: dimmman ( dimmman ) - 2012-01-04 01:44:29 PST
Details: Looking at the code (v1.6.14, upnptools.c) for UpnpResolveURL
and UpnpResolveURL2 it shows that the ExitFunction: always returns
UPNP_E_SUCCESS.
I'm farily sure it's a simple mistake that should have been "return ret;"
in both cases.
Br,
Jonny
(cherry picked from commit 3b33626e2f34f73beb78fbe899abb05a47dec494)
Adding two new functions (UpnpSendAdvertisementLowPower and
UpnpUnRegisterRootDeviceLowPower) which can be used to specify values
for the three SSDP headers defined by UPnP Low Power. Those headers are
Powerstate, SleepPeriod and RegistrationState.
(cherry picked from commit 98e4f938d63226bcb623dd7d9cd1855482318534)
Changing IN6_IS_ADDR_GLOBAL to accept all IPv6 addresses which have a
2000::/3 prefix.
(cherry picked from commit 92c93a8010a70bc9b8d62db88648b5ed6de7794b)
Do not answer to M-SEARCH using HTTP version 1.0 as specified by the
UPnP Device Architecture.
(cherry picked from commit 6c6fb3707f809b7bf7373b2fbe496913255f6227)
Putting all access to ssdpReqSock4 and ssdpReqSock6 under
INCLUDE_CLIENT_APIS compilation flag to be able to compile when
client part of library is disable.
(cherry picked from commit 0996d23318e4249f37f4fb8640f563fd4dcbcd29)
Add a new UpnpRegisterRootDevice4 which allow user to specify a
description URL to be returned for legacy CPs (for example, CPs
searching for a v1 when the device is v2). Most of those CPs does not
work if they found a v2 in the XML description, so this new function is
only used to solve interoperability issues.
(cherry picked from commit 11f9a2bafe15f7ebb38342f26fb91258390a64ef)
This function uses a ThreadPool object as an argument, which is not
supposed to be exported. Also, debug compilation was broken.
(cherry picked from commit 32e510b45abfc99a9c9c6c7addbc21769244ffdb)
Major bug fix in miniserver.c for IPv6, bug was introduced when
changing implementation of get_port in November 20th 2010 ("gena:fix
several compiler warnings" commit).
(cherry picked from commit 063d472f8013f85b73fe4a638e5bcd3f17d4b037)
The files FreeList.h, LinkedList.h, ThreadPool.h and TimerThread.h
from the threautil library were being installed in the include
directory of the library, incorrectly exposing internal data structure
of the library.
(cherry picked from commit 0bbe9f62dff09d718882195a9688aad3340944ab)
Fix for compilation warnings of unused variables in upnpdebug.c in
release builds.
(cherry picked from commit 6c125feea094389ff528a50310e49cd686866c25)
Add 'requiredThreads' field to the ThreadPool structure, to avoid
a race condition when waiting for a new thread to be created. The
race condition occurs when a thread is destroyed while the master
thread is waiting for a new thread to be created.
Thanks to Chuck Thomason for pointing the problem.
Summary: Race condition can hang miniserver thread - ID: 3158591
Details:
Hello,
I have found a race condition in the thread pool handling of
libupnp-1.6.6 that periodically results in the miniserver thread
getting blocked infinitely.
In my setup, I have the miniserver thread pool configured with 1
job per thread, 2 threads minimum, and 50 threads maximum.
Just before the lockup occurs, the miniserver thread pool contains
2 threads: one worker thread hanging around from a previous HTTP
request job (let's call that thread "old_worker") and the
miniserver thread itself.
A new HTTP request comes in. Accordingly, the miniserver enters
schedule_request_job() and then ThreadPoolAdd(). In
ThreadPoolAdd(), the job gets added to the medium-priority queue,
and AddWorker() is called. In AddWorker(), jobs = 1 and threads =
1, so CreateWorker gets called.
When we enter CreateWorker(), tp->totalThreads is 2, so
currentThreads is 3. The function creates a new thread and then
blocks on tp->start_and_shutdown. The miniserver thread expects
the newly created thread to increment tp->totalThreads and then
signal the condition variable to wake up the miniserver thread and
let it proceed.
The newly created thread starts in the WorkerThread() function. It
increments tp->totalThreads to 3, does a broadcast on the
start_and_shutdown condition, and starts running its job. However,
before the miniserver thread wakes up, "old_worker" times out. It
sees that there are no jobs in any queue and that the total number
of threads (3) is more than the minimum (2). As a result, it
reduces tp->totalThreads to 2 and dies.
Now the miniserver thread finally wakes up. It checks
tp->totalThreads and sees that its value is 2, so it blocks on
tp->start_and_shutdown again. It has now "missed" seeing
tp->totalThreads get incremented to 3 and will never be unblocked
again.
When this issue does occur for a server device, the miniserver
port remains open, but becomes unresponsive since the miniserver
thread is stuck. SSDP alive messages keep getting sent out, as
they are handled by a separate thread. Reproducing the issue is
difficult due to the timing coincidence involved, but in my
environment I am presently seeing it at least once a day. I
figured out the sequence described above through addition of my
own debug logs.
The relevant code involved in this bug has not changed
substantially in libupnp-1.6.10, though I am planning to test
against 1.6.10 as well in the near future.
Do you have any input for an elegant fix for this issue?
Thanks,
Chuck Thomason
(cherry picked from commit c4e9757bcf26c48791cc9c4e4f6a355e1faf49e5)
Make these definitions available to programs using the library.
Thanks to Chandra Penke for pointing the problem.
(cherry picked from commit abfa84131803ee0a65bc0382f86cca9065b6e76e)
...without looking in the standard header path. This allows pupnp
to build in xcode.
(cherry picked from commit 9051731a93c76d963b636213f6ca5596e73bce7b)
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 b2a88aa70bd5deeadf597f1ba30e6d8fca606eec)
Currently, http_SendMessage was not able to write to write a buffer
due to a bad use of file_buf instead of buf. This bug was introduced by
the 0197-Doxygen-reformating-compiler-warnings patch.
(cherry picked from commit 2c3bce13bdcf534c77f525c7e7960cad2bf43087)
Currently, Upnp_Event_Subscribe always contains an empty chain in the
Sid parameter. This patch now saves the client Subscription ID in this
parameter so Control Points can see and use the same SID in the
Upnp_Event_Subscribe and in the Upnp_Event structures.
