Re: [libmicrohttpd] memleak in digestauth.c @ check_argument_match()
Thanks, fixed as suggested in SVN 35864 (and yes, very odd that this wasn't caught by static analysis or other runs with valgrind before). -Christian On 06/04/2015 01:22 PM, Andreas Wehrmann wrote: > Hi! > > I was checking a test app in valgrind and much to my surprise it was > complaining about a memleak in libmicrohttpd. > In check_argument_match() a buffer is allocated using strdup() but freed > nowhere. > > I wouldn't have noticed this leak if it wasn't for valgrind because if a URI > is requested without any arguments (my usual case) > the buffer that gets allocated has 'only' a length of 1 byte, thus memory > usage will build up very slowly over time. > > The patch attached fixes it. > Btw. the indentation of that file is a mess, tabs and spaces are mixed :-| > > Regards, > Andreas > 0xE29FC3CC.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[libmicrohttpd] memleak in digestauth.c @ check_argument_match()
Hi!
I was checking a test app in valgrind and much to my surprise it was
complaining about a memleak in libmicrohttpd.
In check_argument_match() a buffer is allocated using strdup() but freed
nowhere.
I wouldn't have noticed this leak if it wasn't for valgrind because if a URI is
requested without any arguments (my usual case)
the buffer that gets allocated has 'only' a length of 1 byte, thus memory usage
will build up very slowly over time.
The patch attached fixes it.
Btw. the indentation of that file is a mess, tabs and spaces are mixed :-|
Regards,
Andreas
--- bla/libmicrohttpd/src/microhttpd/digestauth.c 2015-05-29 12:20:53.027686000 +0200
+++ digestauth.c 2015-06-04 13:11:08.123697504 +0200
@@ -508,7 +508,10 @@
connection,
argp);
if (MHD_YES != test_header (connection, argp, NULL))
- return MHD_NO;
+ {
+free(argb);
+return MHD_NO;
+ }
num_headers++;
break;
}
@@ -527,10 +530,16 @@
connection,
equals);
if (! test_header (connection, argp, equals))
- return MHD_NO;
+ {
+ free(argb);
+ return MHD_NO;
+ }
+
num_headers++;
argp = amper;
}
+
+ free(argb);
/* also check that the number of headers matches */
for (pos = connection->headers_received; NULL != pos; pos = pos->next)
Re: [libmicrohttpd] Expose the fdset events
On Wed, Jun 3, 2015 at 1:08 AM, Christian Grothoff wrote: > Well, the easiest way you can do it now is just ask MHD to run in > 'EPOLL' mode and grab the epoll() FD. Then you can select/poll/epoll on > the MHD epoll() FD. You won't get detailed information about add/remove > events from MHD, but you'll then only have to deal with one FD for all > of MHD in your event set ever, and your overall big-O complexity for all > operations should also be perfect. That only works for platforms with epoll() support. I'll have a go at building a generic event management API today. Simon > My 2 cents > > Christian > > On 06/03/2015 04:33 AM, Simon Newton wrote: >> Digging up a thread from the past... >> >> Is the codebase in a better shape to make this change now? We've run >> into this again now that we've switched to using kevent rather than >> select. >> >> >> If you're looking for existing APIs to model this from, Avahi has a >> watch API [1] which provides fd notifications, and that has worked >> well for us. >> >> [1] http://avahi.org/download/doxygen/struct_avahi_poll.html >> >> >> Simon >>
Re: [libmicrohttpd] Expose the fdset events
I have a change that seems to work, at least I've tested with http & https using an external kqueue/kevent event manager. Christian: do you mind looking over https://github.com/nomis52/libmicrohttpd/pull/1/files which has the API & an example program. If you're happy with the approach I'll clean up the rest of the code so you can review it. Simon On Thu, Jun 4, 2015 at 8:05 AM, Simon Newton wrote: > On Wed, Jun 3, 2015 at 1:08 AM, Christian Grothoff > wrote: >> Well, the easiest way you can do it now is just ask MHD to run in >> 'EPOLL' mode and grab the epoll() FD. Then you can select/poll/epoll on >> the MHD epoll() FD. You won't get detailed information about add/remove >> events from MHD, but you'll then only have to deal with one FD for all >> of MHD in your event set ever, and your overall big-O complexity for all >> operations should also be perfect. > > That only works for platforms with epoll() support. > > I'll have a go at building a generic event management API today. > > Simon > >> My 2 cents >> >> Christian >> >> On 06/03/2015 04:33 AM, Simon Newton wrote: >>> Digging up a thread from the past... >>> >>> Is the codebase in a better shape to make this change now? We've run >>> into this again now that we've switched to using kevent rather than >>> select. >>> >>> >>> If you're looking for existing APIs to model this from, Avahi has a >>> watch API [1] which provides fd notifications, and that has worked >>> well for us. >>> >>> [1] http://avahi.org/download/doxygen/struct_avahi_poll.html >>> >>> >>> Simon >>>
