This list is closed, nobody may subscribe to it.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(2) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(13) |
Feb
(16) |
Mar
(25) |
Apr
(29) |
May
(24) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(12) |
Dec
(1) |
2008 |
Jan
(1) |
Feb
(3) |
Mar
(5) |
Apr
(10) |
May
(6) |
Jun
(12) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(3) |
2009 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(63) |
Apr
(9) |
May
(6) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(30) |
Oct
(9) |
Nov
(8) |
Dec
(8) |
2011 |
Jan
(56) |
Feb
(18) |
Mar
(22) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(1) |
Dec
(3) |
2012 |
Jan
(6) |
Feb
(35) |
Mar
(140) |
Apr
(12) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
From: Tracker i. u. n. <pup...@li...> - 2012-10-30 21:59:54
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-09-24 15:52:10
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-08-19 20:28:37
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-08-19 20:18:35
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-07-15 18:46:49
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-25 17:03:55
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-25 16:42:07
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-25 14:46:13
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-25 14:17:16
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-24 19:13:17
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-08 14:10:57
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-08 11:28:17
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-05-08 10:08:19
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-27 15:45:11
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-27 14:26:02
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-27 09:22:18
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-11 16:51:03
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-11 16:50:04
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-11 14:59:52
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-11 14:21:54
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-05 18:22:04
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-05 17:12:48
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-03 13:12:47
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-02 14:11:48
|
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 |
From: Tracker i. u. n. <pup...@li...> - 2012-04-02 13:49:20
|
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 |