pupnp-tracker — Update notifcations of Tracker items

[pupnp-tracker] [ pupnp-Bugs-3522015 ] total jobs = 100, too many jobs total

[Tracker i. u. n. <pup...@li...>]

Bugs item #3522015, was opened at 2012-04-27 07:26
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3522015&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcelo Roberto Jimenez (mroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: total jobs = 100, too many jobs total

Initial Comment:
Reported by Rafiullah Khan (rafiuk7 at gmail dot com)

Dear sir,
       I found your email ID on libupnp forum. I am using libupnp 1.6.16... I created my control point using hints from tv_ctrlpt sample example.
When I run my written control point or sample, tv_ctrlpt in my lab network where also other UPnP devices are attached to network, I get the following error after like 1 or 2 mins.

total jobs = 100, too many jobs total jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too ...............- - - - -  --- -  - -   -

I found that the problem occurs at the ssdp events, and may be most probably with ixml_document, that generate a lot of threads.

Can you please help me in this regards.

Thank you so much for your time..


Kind Regards,
Rafiullah Khan

----------------------------------------------------------------------

Comment By: Denis Loh ()
Date: 2012-10-30 14:59

Message:
As there is a work-a-round for MediaTomb available, I was wondering if this
bug is already fixed?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3522015&group_id=166957

[pupnp-tracker] [ pupnp-Patches-3571246 ] Fix compilation on GNU/Hurd

[Tracker i. u. n. <pup...@li...>]

Patches item #3571246, was opened at 2012-09-24 08:52
Message generated for change (Tracker Item Submitted) made by pinotree
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3571246&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pino Toscano (pinotree)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix compilation on GNU/Hurd

Initial Comment:
On GNU/Hurd, "BSD" is defined (since it wanted to have a BSD compatibilty), hence leading to use BSD-specific features such as SO_REUSEPORT.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3571246&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3559607 ] Cookie not always given to callback function

[Tracker i. u. n. <pup...@li...>]

Bugs item #3559607, was opened at 2012-08-19 13:28
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3559607&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikko Sysikaski ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Cookie not always given to callback function

Initial Comment:
In libupnp-1.6.17, when polling for events via UpnpSearchAsync, the callback function is not always given the cookie parameter that was given to UpnpSearchAsync. This seems to happen always when the callback is called with event type UPNP_EVENT_RECEIVED after subscribing to an event using UpnpSubscribe. Instead of the correct parameter, the callback function receives a null pointer as cookie.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3559607&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3559598 ] Downloading large documents fails

[Tracker i. u. n. <pup...@li...>]

Bugs item #3559598, was opened at 2012-08-19 13:18
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3559598&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Downloading large documents fails

Initial Comment:
Using libupnp-1.6.17, downloading large (>16K) files using UpnpDownloadXmlDoc fails, returning error code -506 (UPNP_E_OUTOF_BOUNDS), which is not documented as possible return value for UpnpDownloadXmlDoc.

It is possible for user to work around this issue by using a combination of UpnpOpenHttpGet, UpnpReadHttpGet and UpnpCloseHttpGet. However, the same problem seems to exist for other functions too: at least UpnpSendAction fails with the same return code when the server returns a large reply.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3559598&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-1935694 ] Fixed length buffer for UPNP Action URLs breaks applications

[Tracker i. u. n. <pup...@li...>]

Bugs item #1935694, was opened at 2008-04-05 15:33
Message generated for change (Comment added) made by leveret
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=1935694&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: trunk
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Nick Leverton (leveret)
Assigned to: Nick Leverton (leveret)
Summary: Fixed length buffer for UPNP Action URLs breaks applications

Initial Comment:
(forwarded from a Debian user by Debian libupnp package maintainer, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=353169)

When using the UpnpSendActionAsync method (and possibly other Async methods), the SDK stores the URL for the action in a struct UpnpNonblockParam. This has a fixed length array for storing the action URL of 100 characters. Some UPNP servers routinely generate control URLs longer than 100 characters:

http://192.168.0.1:2869/upnphost/udhisapi.dll?control=uuid:xxxxxxxx-b4cb-41ac-827d-xxxxxxxxxxxx+urn:upnp-org:serviceId:ContentDirectory

at src/api/upnpapi.c:2694, the SDK then proceeds to strcpy the control URL to the Param struct, resulting in stack-overwritey-badness.

Our user provided a patch (attached) and adds:

Please find attached a patch which goes some way to fixing this issue. I've only tested it in my current configuration, so I don't know how  this impacts the webserver. I've had to introduce two new functions to  free structures that may be returned by the framework. Not sure how necessary they are, as I think mostly it frees up what it gives you.

----------------------------------------------------------------------

>Comment By: Nick Leverton (leveret)
Date: 2012-07-15 11:46

Message:
Testing if i can respond to this issue, I had problems last time.

----------------------------------------------------------------------

Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-01-25 03:06

Message:
Reopened upon request from Nick.

----------------------------------------------------------------------

Comment By: Nick Leverton (leveret)
Date: 2008-06-18 11:24

Message:
Logged In: YES 
user_id=46394
Originator: YES

Hi Marcelo

One of my users found the patch I supplied causes segfaults (probably some
fault introduced in updating it for 1.6).  I was trying to debug it and got
deeper and deeper into the scheduler and its object management !  So
instead of replicating all your work on 1.8 I just reverted that patch for
my 1.6.6 which is now awaiting upload to Debian.

There is some application porting required to test out 1.8 for the API
naming changes, so I haven't tried that branch yet.  I am confident it will
be better tested than my 1.6 patch already though :-)   Happy to leave this
issue closed for now, I will re-open if needed.

----------------------------------------------------------------------

Comment By: SourceForge Robot (sf-robot)
Date: 2008-06-08 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2008-05-25 12:19

Message:
Logged In: YES 
user_id=67568
Originator: NO

Hi again Nick,

We are about to release the 1.8.x code, and I would like to know it this is
still an issue. We have addressed (I hope) all the external variable length
strings issues by using a new type, UpnpString.

I will leave this as pending, feel free to reopen if there is any problem.

Regards,
Marcelo.

----------------------------------------------------------------------

Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2008-05-05 15:42

Message:
Logged In: YES 
user_id=67568
Originator: NO

Hi Nick,

Thank you for taking the time to look at the new code.

Indeed, we are already using dynamically allocated buffers in the SVN
repository. We hope that any buffer overflow issues remaining be fixed with
this approach.

Also, we are now using opaque data types, so that developers can change the
internal library data structures without breaking the library API. And the
new 1.8.0 code will be IPv6 enabled. IPv6 is functional in the SVN
repository.

There have been lots of changes and now the code needs some testing.

Nevermind about the C/C++ confusion :)

Do you mind if I close this issue? Or would you prefer to leave this open
until 1.8.0 is released and you have tested it?

Regards,
Marcelo.


----------------------------------------------------------------------

Comment By: Nick Leverton (leveret)
Date: 2008-05-05 14:45

Message:
Logged In: YES 
user_id=46394
Originator: YES

Hi Marcelo

You are quite correct, the problem was originally raised against v1.2.1. 
Like you I couldn't see any limit on the length of strings in uPnP so I
just updated the patch and passed it on.  Debian now contains v1.6.5 and
will be updated to 1.6.6 shortly.

The C/C++ confusion was my error based on a poor memory when I wrote the
response to the user, I apologise !

I see in SVN you have some changes planned for release 1.8.0 which address
the problem by using dynamically allocated strings with included length.  I
have only had a quick look, but I think it is a safe approach which should
work reliably in the long term.

Regards
Nick

----------------------------------------------------------------------

Comment By: Nick Leverton (leveret)
Date: 2008-04-10 12:45

Message:
Logged In: YES 
user_id=46394
Originator: YES

Hello Marcelo

I formally took over the package "ownership" in Debian only a week ago, so
thanks for your reply !  Unfortunately the user in question stopped using
pupnp whilst there were no updates to it in Debian.  However I thought it
still worth submitting his fix to you.  I've now brought Debian up to 1.6.5
and am eagerly watching your 1.6.6 comments in CVS changelog :-)

As to fixed buffer sizes, I tried to understand the upnp specifications but
I can't remember if it even specified any limits or not.  I would normally
prefer to use dynamically allocated buffers for flexibility towards the
users, but I can see that would be a major piece of work for pupnp due to
the way the Intel library was written with fixed buffers.  I can't take on
too much extra work myself at the moment regrettably :-(

I hope I can provide more contributions in due course.  I have been
concentrating on the packaging rather than the functioning to begin with,
because Debian will soon be going into freeze for its next release.  The
comment about "C++" was my error, I'm sorry.

----------------------------------------------------------------------

Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2008-04-10 11:46

Message:
Logged In: YES 
user_id=67568
Originator: NO

Hi Nick,

First, please accept my apologies for taking so long to answer.

I have read your users complaints and I see the problems.

I don't know what is the current library revision you are using, but since
the first version of libupnp after we started maintaining it (1.4.0) the
size of the buffer is 256 bytes. Not that it matters that much, because the
overflowing problem remains, but you seem to be using a version of the
library that is too old and of course has many already corrected bugs. I
would advise to go to 1.6.x series as quick as possible.

Also, somewhere in the post it has been said that libupnp is a C++ package
and that the patch should have new/delete. This is incorrect, libupnp is
plain C, not C++.

Without thinking too much, we have two solutions to this problem. Either
malloc a new buffer at each request, or use a fixed size and a hard limited
copy. I would prefer the last solution, but only if the UPnP standard poses
the limitation, otherwise we will have to go with the first. Does anyone
know anything about this?

Regards,
Marcelo.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=1935694&group_id=166957

[pupnp-tracker] [ pupnp-Feature Requests-3508818 ] Allow multiple interfaces/ip addresses with UpnpInit

[Tracker i. u. n. <pup...@li...>]

Feature Requests item #3508818, was opened at 2012-03-19 09:34
Message generated for change (Comment added) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841029&aid=3508818&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nicolai Ehemann (mcnetic)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow multiple interfaces/ip addresses with UpnpInit

Initial Comment:
Currently, UpnpInit only allows for one IP address to be used when initializing. As the documentation already mentions, this is problematic in multi-homed scenarios. Here, one can specify the IP address.
But common multi-homes scenarios are mobile devices connected to the second network (for example a corporate network) via vpn. Specifying the ip in this scenario is not only uncomfortable, for end users, it may well be impossible, as the ip addresses constantly change when moving the portable device to other locations (lans/wlans).
Therefore, I suggest changing UpnpInit to allow for connecting to multiple (and consequently all) available interfaces. Applications could then choose to only connect to interfaces of special types (which should probably not be the scope of libupnp).

----------------------------------------------------------------------

>Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-05-25 10:03

Message:
Hi Nicolai,

Sorry for the delay in answering.

I am not interested in developing an API addition, but I only speak for
myself, not for the other (few) developers.

On the other hand, if you provide such a patch, it will be more than
welcome.

Regards,
Marcelo.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841029&aid=3508818&group_id=166957

[pupnp-tracker] [ pupnp-Patches-3529542 ] socket-connect bug fix patch

[Tracker i. u. n. <pup...@li...>]

Patches item #3529542, was opened at 2012-05-24 12:13
Message generated for change (Comment added) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3529542&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: anoop mohan (an00p)
>Assigned to: Marcelo Roberto Jimenez (mroberto)
Summary: socket-connect bug fix patch

Initial Comment:
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). Author: Anoop Mohan (ano...@gm...)

----------------------------------------------------------------------

>Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-05-25 09:42

Message:
Committed, thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3529542&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3524675 ] new callback genarated after UpnpUnRegisterClient()

[Tracker i. u. n. <pup...@li...>]

Bugs item #3524675, was opened at 2012-05-08 03:08
Message generated for change (Comment added) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yoichi NAKAYAMA (yoichi)
Assigned to: Yoichi NAKAYAMA (yoichi)
Summary: new callback genarated after UpnpUnRegisterClient()

Initial Comment:
Description of UpnpUnRegisterClient() says
"The UPnP Library generates no more callbacks after this function returns".
But send_search_result() in ssdp_ctrlpt.c may generate one via function pointer determined at TPJobInit call.

----------------------------------------------------------------------

>Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-05-25 07:46

Message:
Hi Yiochi,

Maybe calling the callback with HandleReadLock(), instead of HandleLock(),
which is equivalent to HandleWriteLock()?

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-05-08 07:10

Message:
I found that callback is invoked AFTER HandleUnlock() in
GenaAutoRenewSubscription(), gena_process_notification_event().
I think there are possibilities to invoke callback after
UpnpUnRegisterClient(), too:

1. Thread-A stores callback pointer to local variable
2. Thread-A releases lock
3. Thread-B call UpnpUnRegisterClient() and it returns
4. Thread-A invoke callback via local variable

Invoke callback inside locked region will avoid the possibility, but I'm
worry about that it may cause deadlocks depending on user supplied callback
function. 

Any suggestions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3524686 ] Inconsistent types

[Tracker i. u. n. <pup...@li...>]

Bugs item #3524686, was opened at 2012-05-08 04:28
Message generated for change (Comment added) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524686&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: xml
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tieske (tieske8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent types

Initial Comment:
Methods ixmlDocument_createAttribute() and ixmlDocument_createAttributeEx() both take a 'name' argument typed as 'char*', for consistency this should be type 'DOMString'

(Previously posted this on Github, sorry about that, closed it there)

----------------------------------------------------------------------

>Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-05-25 07:17

Message:
Hi Tieske,

You are correct. If you can post a patch, I will apply it. Or if you
prefer, do a pull request on github.

Regards,
Marcelo.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524686&group_id=166957

[pupnp-tracker] [ pupnp-Patches-3529542 ] socket-connect bug fix patch

[Tracker i. u. n. <pup...@li...>]

Patches item #3529542, was opened at 2012-05-24 12:13
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3529542&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: socket-connect bug fix patch

Initial Comment:
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). Author: Anoop Mohan (ano...@gm...)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841028&aid=3529542&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3524675 ] new callback genarated after UpnpUnRegisterClient()

[Tracker i. u. n. <pup...@li...>]

Bugs item #3524675, was opened at 2012-05-08 03:08
Message generated for change (Comment added) made by yoichi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yoichi NAKAYAMA (yoichi)
Assigned to: Yoichi NAKAYAMA (yoichi)
Summary: new callback genarated after UpnpUnRegisterClient()

Initial Comment:
Description of UpnpUnRegisterClient() says
"The UPnP Library generates no more callbacks after this function returns".
But send_search_result() in ssdp_ctrlpt.c may generate one via function pointer determined at TPJobInit call.

----------------------------------------------------------------------

>Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-05-08 07:10

Message:
I found that callback is invoked AFTER HandleUnlock() in
GenaAutoRenewSubscription(), gena_process_notification_event().
I think there are possibilities to invoke callback after
UpnpUnRegisterClient(), too:

1. Thread-A stores callback pointer to local variable
2. Thread-A releases lock
3. Thread-B call UpnpUnRegisterClient() and it returns
4. Thread-A invoke callback via local variable

Invoke callback inside locked region will avoid the possibility, but I'm
worry about that it may cause deadlocks depending on user supplied callback
function. 

Any suggestions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3524686 ] Inconsistent types

[Tracker i. u. n. <pup...@li...>]

Bugs item #3524686, was opened at 2012-05-08 04:28
Message generated for change (Tracker Item Submitted) made by tieske8
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524686&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: xml
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tieske (tieske8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent types

Initial Comment:
Methods ixmlDocument_createAttribute() and ixmlDocument_createAttributeEx() both take a 'name' argument typed as 'char*', for consistency this should be type 'DOMString'

(Previously posted this on Github, sorry about that, closed it there)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524686&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3524675 ] new callback genarated after UpnpUnRegisterClient()

[Tracker i. u. n. <pup...@li...>]

Bugs item #3524675, was opened at 2012-05-08 03:08
Message generated for change (Tracker Item Submitted) made by yoichi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Yoichi NAKAYAMA (yoichi)
Assigned to: Yoichi NAKAYAMA (yoichi)
Summary: new callback genarated after UpnpUnRegisterClient()

Initial Comment:
Description of UpnpUnRegisterClient() says
"The UPnP Library generates no more callbacks after this function returns".
But send_search_result() in ssdp_ctrlpt.c may generate one via function pointer determined at TPJobInit call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3524675&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Settings changed) made by yoichi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-04-27 02:22

Message:
Sorry I was not sure how to close this, but now I closed it!


----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-04-11 09:51

Message:
Thanks!
(Sorry I was tied up with day job and could not follow up on this quickly.)

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 11:22

Message:
zephyrus,
I've pushed Commit:34a77cc095a6be89a7cb2d71202364c3cc7e8d26
in branch-1.6.x. Close this issue if it is OK.
Regards,

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3522015 ] total jobs = 100, too many jobs total

[Tracker i. u. n. <pup...@li...>]

Bugs item #3522015, was opened at 2012-04-27 07:26
Message generated for change (Tracker Item Submitted) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3522015&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marcelo Roberto Jimenez (mroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: total jobs = 100, too many jobs total

Initial Comment:
Reported by Rafiullah Khan (rafiuk7 at gmail dot com)

Dear sir,
       I found your email ID on libupnp forum. I am using libupnp 1.6.16... I created my control point using hints from tv_ctrlpt sample example.
When I run my written control point or sample, tv_ctrlpt in my lab network where also other UPnP devices are attached to network, I get the following error after like 1 or 2 mins.

total jobs = 100, too many jobs total jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too many jobstotal jobs = 100, too ...............- - - - -  --- -  - -   -

I found that the problem occurs at the ssdp events, and may be most probably with ixml_document, that generate a lot of threads.

Can you please help me in this regards.

Thank you so much for your time..


Kind Regards,
Rafiullah Khan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3522015&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Comment added) made by zephyrus00jp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-04-27 02:22

Message:
Sorry I was not sure how to close this, but now I closed it!


----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-04-11 09:51

Message:
Thanks!
(Sorry I was tied up with day job and could not follow up on this quickly.)

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 11:22

Message:
zephyrus,
I've pushed Commit:34a77cc095a6be89a7cb2d71202364c3cc7e8d26
in branch-1.6.x. Close this issue if it is OK.
Regards,

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Comment added) made by zephyrus00jp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-04-11 09:51

Message:
Thanks!
(Sorry I was tied up with day job and could not follow up on this quickly.)

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 11:22

Message:
zephyrus,
I've pushed Commit:34a77cc095a6be89a7cb2d71202364c3cc7e8d26
in branch-1.6.x. Close this issue if it is OK.
Regards,

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Settings changed) made by zephyrus00jp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 11:22

Message:
zephyrus,
I've pushed Commit:34a77cc095a6be89a7cb2d71202364c3cc7e8d26
in branch-1.6.x. Close this issue if it is OK.
Regards,

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3516857 ] Fix non-IPv6 build breakage

[Tracker i. u. n. <pup...@li...>]

Bugs item #3516857, was opened at 2012-04-11 07:21
Message generated for change (Comment added) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3516857&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
>Group: branch-1.6.x
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Gustavo Zacarias (gustavoz)
>Assigned to: Marcelo Roberto Jimenez (mroberto)
Summary: Fix non-IPv6 build breakage

Initial Comment:
ssdp_device.c uses IPV6_MULTICAST_HOPS even in non-IPv6 scenarios, which isn't guaranteed to exist.
Exclude the block based on the INET_IPV6 definition.


----------------------------------------------------------------------

>Comment By: Marcelo Roberto Jimenez (mroberto)
Date: 2012-04-11 07:59

Message:
Committed, thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3516857&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3516857 ] Fix non-IPv6 build breakage

[Tracker i. u. n. <pup...@li...>]

Bugs item #3516857, was opened at 2012-04-11 07:21
Message generated for change (Tracker Item Submitted) made by gustavoz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3516857&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: upnp
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gustavo Zacarias (gustavoz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix non-IPv6 build breakage

Initial Comment:
ssdp_device.c uses IPV6_MULTICAST_HOPS even in non-IPv6 scenarios, which isn't guaranteed to exist.
Exclude the block based on the INET_IPV6 definition.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3516857&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Comment added) made by yoichi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

>Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 11:22

Message:
zephyrus,
I've pushed Commit:34a77cc095a6be89a7cb2d71202364c3cc7e8d26
in branch-1.6.x. Close this issue if it is OK.
Regards,

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3507819 ] Use of thread-unsafe gmtime() in httpreadwrite.c

[Tracker i. u. n. <pup...@li...>]

Bugs item #3507819, was opened at 2012-03-18 06:31
Message generated for change (Comment added) made by yoichi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: zephyrus (zephyrus00jp)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use of thread-unsafe gmtime() in httpreadwrite.c

Initial Comment:
In upnp/src/genlib/net/http/httpreadwrite.c, a function called gmtime() is used
to obtain a date string.
However, it is  not thread-safe..
.   
Found by running the code using valgrind.

Patch attached.

(Sorry, I am still new to git and I could not fix
the commit message that contained incorrect function name, and
so hand-editied it. I have no idea if there is any ill-effect to the resulting patch
although I don't see any proble with it ;-)


----------------------------------------------------------------------

>Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-04-05 10:12

Message:
zephyrus,
I found gmtime is used in webserver.c too.
I'll commit a change for both.
Regards,

----------------------------------------------------------------------

Comment By: zephyrus (zephyrus00jp)
Date: 2012-03-25 03:38

Message:
I uploaded a patch that takes of WIN32 issue.

----------------------------------------------------------------------

Comment By: Yoichi NAKAYAMA (yoichi)
Date: 2012-03-23 22:27

Message:
Windows version of gmtime uses thread local variable:
http://msdn.microsoft.com/en-us/library/0z9czt0w(v=vs.80).aspx
> Both the 32-bit and 64-bit versions of gmtime, mktime, mkgmtime, and
localtime
>  all use a single tm structure per thread for the conversion. Each call
to one of 
> these functions destroys the result of any previous call.

Therefore, keep original code in #ifdef WIN32.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3507819&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3514145 ] Memory leak fix in threadutil

[Tracker i. u. n. <pup...@li...>]

Bugs item #3514145, was opened at 2012-04-02 06:49
Message generated for change (Settings changed) made by mroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: threadutil
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Fabrice Fontaine (ffontaine)
Assigned to: Fabrice Fontaine (ffontaine)
Summary: Memory leak fix in threadutil

Initial Comment:
Put thread in a detached state when calling ithread_create otherwise in
some circumstances, thread can end before the call to ithread_detach.

I will commit a fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3514145 ] Memory leak fix in threadutil

[Tracker i. u. n. <pup...@li...>]

Bugs item #3514145, was opened at 2012-04-02 06:49
Message generated for change (Settings changed) made by ffontaine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: threadutil
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Fabrice Fontaine (ffontaine)
Assigned to: Fabrice Fontaine (ffontaine)
Summary: Memory leak fix in threadutil

Initial Comment:
Put thread in a detached state when calling ithread_create otherwise in
some circumstances, thread can end before the call to ithread_detach.

I will commit a fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957

[pupnp-tracker] [ pupnp-Bugs-3514145 ] Memory leak fix in threadutil

[Tracker i. u. n. <pup...@li...>]

Bugs item #3514145, was opened at 2012-04-02 06:49
Message generated for change (Tracker Item Submitted) made by ffontaine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: threadutil
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabrice Fontaine (ffontaine)
Assigned to: Fabrice Fontaine (ffontaine)
Summary: Memory leak fix in threadutil

Initial Comment:
Put thread in a detached state when calling ithread_create otherwise in
some circumstances, thread can end before the call to ithread_detach.

I will commit a fix.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=841026&aid=3514145&group_id=166957