dclib-devel Mailing List for dlib C++ Library (Page 6)
Brought to you by:
davisking
Menu
▾
▴
dclib-devel — A list for developers to discuss issues
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(7) |
Nov
(3) |
Dec
|
| 2009 |
Jan
(4) |
Feb
(3) |
Mar
(4) |
Apr
(3) |
May
(9) |
Jun
(5) |
Jul
(7) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2010 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2017 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(10) |
Sep
|
Oct
(12) |
Nov
(1) |
Dec
(20) |
| 2018 |
Jan
(11) |
Feb
(10) |
Mar
(8) |
Apr
|
May
(8) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Davis K. <da...@dl...> - 2010-09-16 00:31:53
|
The dlib GUI isn't quite as full featured as others like Qt are. So in particular, there isn't currently any way to tell a scroll bar to go to the bottom. There is also only one style of text box, although it does let you define your own. The interface you have to implement is defined here: http://dlib.net/dlib/gui_widgets/style_abstract.h.html#text_box_style and you can look at the default style here for a working example: header: http://dlib.net/dlib/gui_widgets/style.h.html#text_box_style_default <http://dlib.net/dlib/gui_widgets/style.h.html#text_box_style_default> body: http://dlib.net/dlib/gui_widgets/style.cpp.html#draw_text_box <http://dlib.net/dlib/gui_widgets/style.cpp.html#draw_text_box>I'm not sure what you mean by a resizable bool? All the examples I have are in the examples folder. There are 48 of them already, how many do you really need? :) If you are looking for a bigger example involving the GUI you should look at the bayes_net_gui_ex.cpp. It's moderately large and has a lot of interesting things going on in it. Cheers, Davis On Wed, Sep 15, 2010 at 7:59 AM, DaVieS <da...@im...> wrote: > Hi Davis. > > I'm writing you because I get stucked some GUI funcs. > > Could you please tell me an example for these: > > - How can I use and apply a style on text_box > - How can I handle a resizable bool on drawable_window > - How can I set text_box's scroll to be stay always bottom, so I want see > a last line. > > Thank You! > > BTW, > > Can you share me more examples, or applications' source what uisng dlib if > you have? > > Waiting for your reply, Regards! > |
|
From: Davis K. <dav...@us...> - 2010-04-11 16:53:38
|
I thought about doing 1 when I made the read_write_mutex but doing so requires it to keep something like a std::set<thread_id> to track which threads currently have read locks. Doing that would make the read_write_mutex a lot slower and I think that's overkill for what is basically just the convenience of not needing to call unlock_readonly() before you call lock(). Is there anything that is particularly difficult to do without this feature? 2. If you want to submit a patch for these two functions then that would be cool :) They would need to be implemented for POSIX and win32 systems and should probably go into the misc_api section. On Sun, Apr 11, 2010 at 12:35 PM, Steven Van Ingelgem <st...@va... > wrote: > 1) Upgrade/downgrade a read_write mutex to/from read <-> write > > 2) in analogy with get_thread_id : get_pid() & get_parent_pid() [in Linux: > getpid & getppid] > > |
|
From: Steven V. I. <st...@va...> - 2010-04-11 16:35:23
|
1) Upgrade/downgrade a read_write mutex to/from read <-> write 2) in analogy with get_thread_id : get_pid() & get_parent_pid() [in Linux: getpid & getppid] |
|
From: Steven V. I. <st...@va...> - 2010-01-08 10:19:23
|
Hi, I am using svnsync on the dlib repository to keep a local copy (for several reasons though mainly because i use it heavily in several projects). Although the svnsync works fine, after a while I get this error: svnsync: Server sent unexpected return value (403 Forbidden) in response to CHECKOUT request for '/svn/dlib/!svn/ver/3340/trunk/dlib/svm/kernel.h' This is actually the 2nd time I already got this error. Synching everything from scratch makes it work again... Do you have any ideas why? I am synching still several other projects from sourceforge and with the others I didn't have this kind of issues yet. Grtz, Steven |
|
From: Davis K. <dav...@us...> - 2009-12-04 22:15:01
|
Glad you like it.
This is partly my fault :) There should be a try/catch block around the
code in main(). So if you put something like this:
try
{
// all the code in main()
}
catch (std::exception& e)
{
cout << e.what() << endl;
cin.get(); // pause the program until user hits enter
}
I'm pretty confident that you will get the message (it is inside the
dlib::bobyqa_failure exception) that says "Return from BOBYQA because the
objective function has been called max_f_evals times." With GCC you end up
getting the error message no matter what you do but with Visual Studio you
end up getting a weird crash. I'll add some try/catch blocks to the example
in the next release.
Anyway, if you change the 100 (the last argument to find_min_bobyqa) to
something bigger it should work. It is actually quite impressive that it
works with 37 dimensions because the algorithm begins by sampling 37*2+1
times and then only has 25 allowable samples of the objective function to
get within 1e-6 of the optimum. That's pretty good without using any
gradient information :)
Cheers,
Davis
On Fri, Dec 4, 2009 at 2:59 PM, Michele Conconi <mic...@un...>wrote:
> Hi davis,
>
> I first want to thank you for the amazing job done with this library. I
> really like it.
> I have a question that make me crazy. I would use bobyqa optimization
> method. My input array as dimension 41, and this should not have any
> influence. Unfortunately it seems to me that the bobyqa doesn't like input
> bigger than 37.
> If you try the follwing code, essentially one of the example of the dlib,
> just changing the dimension of my input my program stop working giving me
> the error
>
> dlib::bobyqa_failure at memory location 0x00dbf334..
>
> I am using visual studio 2005 for compile the code. Do you have any idea?
> Thanks in advance
>
> Michele
>
>
> #include "dlib/optimization.h"
> #include <iostream>
>
> using namespace std;
> using namespace dlib;
>
> typedef matrix<double,0,1> column_vector;
>
> class test_function
> {
> public:
>
> test_function (
> const column_vector& input
> )
> {
> target = input;
> }
>
> double operator() ( const column_vector& arg) const
> {
> // return the mean squared error between the target vector and the
> input vector
> return mean(squared(target-arg));
> }
>
> private:
> column_vector target;
> };
>
> //
> ----------------------------------------------------------------------------------------
>
> int main()
> {
> // make a column vector of length 2
> column_vector starting_point;
> column_vector target;
>
> int n = 37; //changing n to 38 causes brake
> target.set_size(n);
> starting_point.set_size(n);
>
> for(int i =0;i<n;i++)
> {
> starting_point(i)=-4;
> target(i)=1;
> }
>
> find_min_bobyqa(test_function(target),
> starting_point,
> 2*n+1, // number of interpolation points
> uniform_matrix<double>(n,1, -1e100), // lower bound
> constraint
> uniform_matrix<double>(n,1, 1e100), // upper bound
> constraint
> 10, // initial trust region radius
> 1e-6, // stopping trust region radius
> 100 // max number of objective function evaluations
> );
> cout << starting_point << endl;
> }
> --
> * Eng. Michele Conconi*
> Ph.D. student
> DIEM - Dept. of Mechanical Engineering
> Alma Mater Studiorum - University of Bologna
> Viale Risorgimento 2, 40136, Bologna, Italy
> Email: mic...@un...
> Website: http://www.diem.ing.unibo.it/grab
> Office: (+39) 051 20 93451
> Mobile: (+39) 329 0287996
>
>
>
> * INFORMAZIONE RISERVATA E CONFIDENZIALE *
> Questo messaggio contiene informazioni riservate e confidenziali.
> Se il lettore non fosse il destinatario del messaggio, inoltrato e ricevuto
> per errore,
> il testo dovrà essere immediatamente cancellato dal computer del ricevente.
> E' assolutamente proibita qualunque circolazione, disseminazione o
> copia del messaggio spedito e/o ricevuto per errore.
>
> * CONFIDENTIALITY and WARNING NOTICE *
> This message may contain legally privileged or confidential information.
> If the reader is not the intended recipient, you received this message in
> error
> and it should therefore be deleted from your computer at once.
> Any dissemination, distribution and copying of a message
> mistakenly sent or received is strictly forbidden.
>
|
|
From: Davis K. <dav...@us...> - 2009-10-08 10:32:49
|
Glad you like it :) I feel a little embarrassed to say that I haven't really played around with Python much at all. So I don't know what is involved in making a proper Python wrapper. I can't imagine it is very difficult though. Cheers, Davis On Thu, Oct 8, 2009 at 5:04 AM, M.A. Piccolino-Boniforti <ma...@ca...>wrote: > Dear Davis > > first of all, thank you for your great library. I am very interested in the > RVM learner, and since I have the rest of my code in Python, I was > considering wrapping some of dlib's functionality. I was wondering if you > have had any experience/success story with wrapping dlib or parts of it, > particularly with SWIG. > > Best, > Marco > > |
|
From: Davis K. <dav...@us...> - 2009-09-23 11:48:47
|
It's really just a combination of the SVM solver from the paper Pegasos: Primal estimated sub-gradient solver for SVM (2007) by Yoram Singer, Nathan Srebro and the sparsification method from this other paper, The Kernel Recursive Least Squares Algorithm by Yaakov Engel. The kcentroid implements Engel's sparsification trick in a nice reuseable way and svm_pegasos is basically straight out of Singer's paper. There are also a lot of comments in the code. I also added something to help automatically adjust the tolerance (this is the parameter of Engel's ALD condition). So when you ask a kcentroid to only use so many dictionary vectors all it really does is estimate the tolerance that would have caused you to use only that many and then to discard vectors above that threshold. But this is a minor and straightforward addition and doesn't change the results. It just makes life easier on the user. Cheers, Davis 2009/9/23 Q. W. Xiao <qw...@li...> > Dear Mr. King, > > I met the dlib C++ library today, and I am very interested in the > impletation of svm_pegasos. You said that "this object uses the kcentroid > object to maintain a sparse approximation of the learned decision function", > and then “the number of support vectors in the resulting decision function > is also unrelated to the size of the dataset”. This is a very attractive > property. Could you please provide some materials giving the details of this > method? > > Best regards, > > Quan-Wu Xiao > ------------------------------ > Invite your mail contacts to join your friends list with Windows Live > Spaces. It's easy! Try it!<http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us> > |
|
From: Steven V. I. <st...@va...> - 2009-08-06 17:33:30
|
That seemed to fix it... Thanks :) 2009/8/6 Davis King <dav...@gm...> > I think so. I just checked in a change that I think will fix this. I'm > not sure though so let me know if it works or not. > > Cheers, > Davis > > > On Thu, Aug 6, 2009 at 10:45 AM, Steven Van Ingelgem < > st...@va...> wrote: > >> In file included from >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads.h:17, >> from >> /home/steven/vitruvius/externals/dlib/smart_pointers/shared_ptr_thread_safe.h:12, >> from >> /home/steven/vitruvius/externals/dlib/smart_pointers_thread_safe.h:6, >> from /home/steven/vitruvius/include/FileWrapper.hpp:8, >> from /home/steven/vitruvius/include/Task.hpp:5, >> from /home/steven/vitruvius/include/DB.hpp:11, >> from /home/steven/vitruvius/src/DB.cpp:1: >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:88: >> error: ISO C++ forbids declaration of âshared_ptr_thread_safeâ with no type >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:88: >> error: expected â;â before â<â token >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h: >> In member function âbool dlib::future<T>::is_ready() constâ: >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:79: >> error: âtpâ was not declared in this scope >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h: >> At global scope: >> /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:931: >> error: ISO C++ forbids declaration of âshared_ptr_thread_safeâ with no type >> >> In FileWrapper.hpp I include "smart_pointers_thread_safe.h". >> What I am thinking is that somehow there is a wrong inclusion order? >> Grtz, >> Steven >> > > |
|
From: Davis K. <dav...@gm...> - 2009-08-06 15:27:28
|
I think so. I just checked in a change that I think will fix this. I'm not sure though so let me know if it works or not. Cheers, Davis On Thu, Aug 6, 2009 at 10:45 AM, Steven Van Ingelgem <st...@va...>wrote: > In file included from > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads.h:17, > from > /home/steven/vitruvius/externals/dlib/smart_pointers/shared_ptr_thread_safe.h:12, > from > /home/steven/vitruvius/externals/dlib/smart_pointers_thread_safe.h:6, > from /home/steven/vitruvius/include/FileWrapper.hpp:8, > from /home/steven/vitruvius/include/Task.hpp:5, > from /home/steven/vitruvius/include/DB.hpp:11, > from /home/steven/vitruvius/src/DB.cpp:1: > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:88: > error: ISO C++ forbids declaration of âshared_ptr_thread_safeâ with no type > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:88: > error: expected â;â before â<â token > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h: > In member function âbool dlib::future<T>::is_ready() constâ: > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:79: > error: âtpâ was not declared in this scope > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h: > At global scope: > /home/steven/vitruvius/externals/dlib/smart_pointers/../threads/thread_pool_extension.h:931: > error: ISO C++ forbids declaration of âshared_ptr_thread_safeâ with no type > > In FileWrapper.hpp I include "smart_pointers_thread_safe.h". > What I am thinking is that somehow there is a wrong inclusion order? > Grtz, > Steven > |
|
From: Davis K. <dav...@us...> - 2009-07-24 14:20:36
|
My first guess would be that you are limiting it to too few support vectors. Underneath the svm_pegasos algorithm in dlib is an object (the kcentroid) that basically just keeps a linearly independent set of sample vectors. If you tell svm_pegasos to use only 20 "support vectors" then the kcentroid internally tries to find a set of 20 sample vectors that best span the vector space induced by the kernel you use. The resulting decision function is a linear combination of these vectors so if, as you noted, it picks bad ones then you most likely won't get a good answer. But if you picked ones that really did span the space covered by your samples then you could apply an SVM learning algorithm using just that set and there wouldn't be any local minima to get stuck in. The catch is you have to pick a nice spanning set somehow. This is what dlib::kcentroid tries to do and svm_pegasos is built on stop of it. So the success of the dlib pegasos implementation is predicated on the capability of the kcentroid to crate a good spanning set. So what do you do right? I use svm_pegasos all the time and there are some things you have to watch for related to how it approximates the spanning set of vectors. The first is if you set the tolerance too high then it might not use enough support vectors even if you set the limit to 100000. So for example, the other day I was using it and it tried to use just 1 support vector. Obviously no good. So if the number of SVs you get out of the algorithm is less than whatever you set as the max allowable number (via set_max_num_sv()) then this is because of the tolerance value being large. The default is 0.01 but 0.001 is sometimes more appropriate. I should probably change it to be the default. As an aside, the reason I don't depsense with the tolerance (essentially setting it to 0) and let the cap on support vectors be the only thing that determines how many you end up with is because using a small tolerance and a SV cap together tends to make the algorithm a whole lot faster. The only problem is when the tolerance is too big, then you run into trouble. But this is easy to spot. Similarly, if you just set the SV limit to be too low to accurately represent the span of all the samples (in the feature space induced by your kernel) then the result will probably be chaotic and bad. So try using more. The only times I have seen svm_pegasos get weird are when I was using too few SVs. The more you use the slower it gets but it also gets more accurate. But usually, at least with the datasets I typically encounter, I get by just fine with under about 150 support vectors. Often under half that is fine. But it all depends on your dataset. For example, if you had a 2D dataset that was a checkerboard and you wanted to separate the white squares from the black squares you would need, at the very minimum (assuming you used a gaussian kernel), a number of support vectors equal to the number of squares on your board. My second guess is that you aren't letting the algorithm run long enough. Are you using the batch() or verbose_batch() training adapters (like in this example: http://dclib.sourceforge.net/svm_pegasos_ex.cpp.html)? I would say let the algorithm run until the learning rate has dropped below something like 0.1. If you stop the algorithm before convergence then it definitely won't work well. Note that the time it takes to converge is also a function of what you set as the value of lambda (I typically use lambda values between 1e-4 and 1e-7, but YMMV). What kernel are you using? Another thing to think about is trying to remove some features. Generally, the more features you have the more vectors it takes to span the space inhabited by your samples. There are a lot of feature selection algorithms out there. Currently there is only one in dlib (the rank_features() function) and you might give it a go and see what it says. Anyway, I'm carrying on... I would suggest setting the tolerance to 0.001 and trying maybe a max SV number of 100 and seeing what that gets you as a starting point. I would also make sure you normalized your features if you haven't already. That usually helps a lot (you might use dlib::vector_normalizer). Hope the above helps. Certainly let me know if it doesn't. I'm just an engineer from Maryland. Not much to tell really :) I work in a group at Northrop Grumman that does a lot of image processing and computer vision kinds of things. They don't sponsor dlib or anything though. It is just a project I started back as an undergrad and work on for fun on my own time. Cheers, Davis On Fri, Jul 24, 2009 at 8:35 AM, Alex Siegel <al...@st...> wrote: > I think I understand the pegasos API pretty well, and I've read the > relevant research papers. One aspect that has been a source of frustration > is the lack of predictability in the quality of the output decision > function. As I'm searching the parameter space for optimal values, I'm > finding that very small changes produce large, random variations in the > classification percentage. Adding or removing features has a similar effect. > It seems like pegasos is too easily trapped in local minima during its > optimization, and it's making poor decisions about what support vectors to > start with. The data I'm working with is extremely noisy, but there is a lot > of it (65,000 samples with 50 features). I'd appreciate some insight into > how to improve performance. > > Frankly, I'm also a little curious about you as a person. Your developer > page has no information on it. Where do you live? Where do you work? > > > On Thu, Jul 23, 2009 at 11:42 AM, Davis King < > dav...@us...> wrote: > >> Thanks, good to know you find it useful :) I'm not particular, you can >> email me and the developer list, or post in the help or open discussion >> forms on dlib's sourceforge page. Whatever floats your boat. >> >> So what's your question? >> >> Cheers, >> Davis > > > |
|
From: Alex S. <al...@st...> - 2009-07-24 13:05:36
|
I think I understand the pegasos API pretty well, and I've read the relevant research papers. One aspect that has been a source of frustration is the lack of predictability in the quality of the output decision function. As I'm searching the parameter space for optimal values, I'm finding that very small changes produce large, random variations in the classification percentage. Adding or removing features has a similar effect. It seems like pegasos is too easily trapped in local minima during its optimization, and it's making poor decisions about what support vectors to start with. The data I'm working with is extremely noisy, but there is a lot of it (65,000 samples with 50 features). I'd appreciate some insight into how to improve performance. Frankly, I'm also a little curious about you as a person. Your developer page has no information on it. Where do you live? Where do you work? On Thu, Jul 23, 2009 at 11:42 AM, Davis King < dav...@us...> wrote: > Thanks, good to know you find it useful :) I'm not particular, you can > email me and the developer list, or post in the help or open discussion > forms on dlib's sourceforge page. Whatever floats your boat. > > So what's your question? > > Cheers, > Davis |
|
From: Davis K. <dav...@us...> - 2009-07-23 16:42:44
|
Thanks, good to know you find it useful :) I'm not particular, you can email me and the developer list, or post in the help or open discussion forms on dlib's sourceforge page. Whatever floats your boat. So what's your question? Cheers, Davis On Thu, Jul 23, 2009 at 11:03 AM, Alex Siegel <al...@st...> wrote: > Hi. My name is Alex Siegel, and I’ve been using the pegasos svm > implementation in dlib, and it’s working very well for me. You’ve put > together an excellent library. I do have some questions, though. What’s the > best place to have that conversation? Is there a forum that you post to > regularly? What is the best way to contact you? > > Alex > > |
|
From: Davis K. <dav...@gm...> - 2009-07-08 21:09:13
|
Cool. I just fixed this and checked it in. On Wed, Jul 8, 2009 at 5:14 AM, Steven Van Ingelgem <st...@va...>wrote: > C:\TEMP\SVN\server_monitor\build_mingw>mingw32-make > Scanning dependencies of target dlib > [ 1%] Building CXX object > externals/dlib/CMakeFiles/dlib.dir/all/source.obj > cc1plus.exe: warnings being treated as errors > In file included from > C:\TEMP\SVN\server_monitor\externals\dlib\all\source.cpp:60: > C:\TEMP\SVN\server_monitor\externals\dlib\all\/../gui_core/gui_core_kernel_1.cpp: > In function 'bool dlib::gui_core_kernel_1_globals::map_keys(long uns > igned int, bool, bool, long unsigned int&, bool&)': > C:\TEMP\SVN\server_monitor\externals\dlib\all\/../gui_core/gui_core_kernel_1.cpp:411: > error: suggest parentheses around '&&' within '||' > mingw32-make[2]: *** [externals/dlib/CMakeFiles/dlib.dir/all/source.obj] > Error 1 > mingw32-make[1]: *** [externals/dlib/CMakeFiles/dlib.dir/all] Error 2 > mingw32-make: *** [all] Error 2 > > > This is when compiling with MinGW 4.4.0 on Windows. > > > Grtz, > Steven > |
|
From: Steven V. I. <st...@va...> - 2009-07-08 09:15:16
|
C:\TEMP\SVN\server_monitor\build_mingw>mingw32-make Scanning dependencies of target dlib [ 1%] Building CXX object externals/dlib/CMakeFiles/dlib.dir/all/source.obj cc1plus.exe: warnings being treated as errors In file included from C:\TEMP\SVN\server_monitor\externals\dlib\all\source.cpp:60: C:\TEMP\SVN\server_monitor\externals\dlib\all\/../gui_core/gui_core_kernel_1.cpp: In function 'bool dlib::gui_core_kernel_1_globals::map_keys(long uns igned int, bool, bool, long unsigned int&, bool&)': C:\TEMP\SVN\server_monitor\externals\dlib\all\/../gui_core/gui_core_kernel_1.cpp:411: error: suggest parentheses around '&&' within '||' mingw32-make[2]: *** [externals/dlib/CMakeFiles/dlib.dir/all/source.obj] Error 1 mingw32-make[1]: *** [externals/dlib/CMakeFiles/dlib.dir/all] Error 2 mingw32-make: *** [all] Error 2 This is when compiling with MinGW 4.4.0 on Windows. Grtz, Steven |
|
From: Davis K. <dav...@us...> - 2009-07-06 02:50:04
|
Glad to be of help :) You might want to take a look at this code specifically: http://dclib.sourceforge.net/dlib/svm/svm.h.html#do_train. That is the main block of code that does SMO. The main action is inside the while loop where it alternates selecting the two best alphas and performing the optimization step Platt talks about. The code inside the find_working_group() function is different from what Platt talks about but still similar. For the details behind why that code is the way it is you need to read the paper "Chang and Lin, Training {nu}-Support Vector Classifiers: Theory and Algorithms" Cheers, Davis On Sun, Jul 5, 2009 at 10:17 PM, Lazaro Bustio Martinez <lb...@gm...>wrote: > Hello Davis... yes, it help me a lot. You'll see, I'm trying to find a > standard SMO algotithm implementation like Platt states in his paper. I'm > studying SMO complexity, basically in how many time SMO spent calculating > kernel function, updating caches and so on; but unfortunately I could not > find any straight SMO implementatios as Platt states in his paper. > Your suggestions help me a lot, thanks again. If you could give some more > information, I´ll appreciate a lot. > > Best regards.. > > Lazaro > > > > > 2009/7/5 Davis King <dav...@us...> > > If you are looking at the svm_ex.cpp ( >> http://dclib.sourceforge.net/svm_ex.cpp.html) example program then you >> are seeing the svm_nu_trainer object (see >> http://dclib.sourceforge.net/ml.html#svm_nu_trainer). It uses the >> standard SMO algorithm and there are some more relevant papers sited in the >> link above. >> >> If you want to know a lot more about SVMs and SMO then the best resource >> available is probably the book Learning with Kernels: Support Vector >> Machines, Regularization, Optimization, and Beyond by Schlkopf and Smola. >> >> Hope that helps. >> >> -Davis >> >> >> On Sun, Jul 5, 2009 at 2:38 AM, Lazaro Bustio Martinez <lb...@gm... >> > wrote: >> >>> Hello... I was looking for an SVM implementation and I found yours... but >>> I can't see wich algorithm for SVM training did you used. Can you give me >>> more information about it? >>> >>> Excuse me my english... >>> >>> Thanks a lot. >>> >>> Lazaro Bustio >>> >> >> > |
|
From: Davis K. <dav...@us...> - 2009-07-05 14:43:08
|
If you are looking at the svm_ex.cpp ( http://dclib.sourceforge.net/svm_ex.cpp.html) example program then you are seeing the svm_nu_trainer object (see http://dclib.sourceforge.net/ml.html#svm_nu_trainer). It uses the standard SMO algorithm and there are some more relevant papers sited in the link above. If you want to know a lot more about SVMs and SMO then the best resource available is probably the book Learning with Kernels: Support Vector Machines, Regularization, Optimization, and Beyond by Schlkopf and Smola. Hope that helps. -Davis On Sun, Jul 5, 2009 at 2:38 AM, Lazaro Bustio Martinez <lb...@gm...>wrote: > Hello... I was looking for an SVM implementation and I found yours... but I > can't see wich algorithm for SVM training did you used. Can you give me more > information about it? > > Excuse me my english... > > Thanks a lot. > > Lazaro Bustio > |
|
From: Davis K. <dav...@us...> - 2009-06-23 11:16:56
|
Are you calling wait() inside the destructor for the object you have that inherits from threaded_object? Not doing that might be the reason. -Davis On Tue, Jun 23, 2009 at 2:22 AM, Steven Van Ingelgem <st...@va...>wrote: > I think this is because the object is deleted, but somehow it is still > reading from it... Can that be? I don't delete threads from anywhere... > > ==06:20:12:05.257 26069== > ==06:20:12:05.257 26069== 2 errors in context 10 of 41: > ==06:20:12:05.257 26069== Invalid read of size 1 > ==06:20:12:05.257 26069== at 0x80DDA93: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:169) > ==06:20:12:05.257 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.257 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.257 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.257 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.257 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.257 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.257 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.257 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.257 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.257 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.257 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.257 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.257 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.257 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.257 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.257 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.257 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.258 26069== > ==06:20:12:05.258 26069== 2 errors in context 11 of 41: > ==06:20:12:05.258 26069== Invalid read of size 1 > ==06:20:12:05.258 26069== at 0x80DDA88: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.258 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.258 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.258 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.258 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.258 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.258 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.258 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.258 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.258 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.258 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.258 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.258 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.258 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.258 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.258 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.258 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.258 26069== > ==06:20:12:05.258 26069== 2 errors in context 12 of 41: > ==06:20:12:05.258 26069== Invalid read of size 1 > ==06:20:12:05.258 26069== at 0x80DDA7D: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.258 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.259 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.259 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.259 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.259 26069== Address 0x41A6E28 is 88 bytes inside a block of > size 104 free'd > ==06:20:12:05.259 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.259 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.259 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.259 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.259 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.259 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.259 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.259 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.259 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.259 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.259 26069== > ==06:20:12:05.259 26069== 2 errors in context 13 of 41: > ==06:20:12:05.259 26069== Invalid read of size 1 > ==06:20:12:05.259 26069== at 0x80DDA93: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:169) > ==06:20:12:05.259 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.259 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.259 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.259 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.259 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.259 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.260 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.260 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.260 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.260 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.260 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.260 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.260 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.260 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.260 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.260 26069== > ==06:20:12:05.260 26069== 2 errors in context 14 of 41: > ==06:20:12:05.260 26069== Invalid read of size 1 > ==06:20:12:05.260 26069== at 0x80DDA88: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.260 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.260 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.260 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.260 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.260 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.260 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.260 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.260 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.260 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.260 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.260 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.261 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.261 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.261 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.261 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.261 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.261 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.261 26069== > ==06:20:12:05.261 26069== 2 errors in context 15 of 41: > ==06:20:12:05.261 26069== Invalid read of size 1 > ==06:20:12:05.261 26069== at 0x80DDA7D: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.261 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.261 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.261 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.261 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.261 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.261 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.261 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.261 26069== Address 0x41A6E28 is 88 bytes inside a block of > size 104 free'd > ==06:20:12:05.261 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.261 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.261 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.261 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.261 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.261 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.261 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.262 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.262 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.262 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.262 26069== > > > > > > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge > conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: > $250. > Need another reason to go? 24-hour hacker lounge. Register today! > > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Dclib-devel mailing list > Dcl...@li... > https://lists.sourceforge.net/lists/listinfo/dclib-devel > > |
|
From: Steven V. I. <st...@va...> - 2009-06-23 06:26:47
|
And here are writes? ==06:20:12:05.254 26069== ==06:20:12:05.254 26069== 2 errors in context 7 of 41: ==06:20:12:05.254 26069== Invalid write of size 1 ==06:20:12:05.254 26069== at 0x80E5063: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:191) ==06:20:12:05.255 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.255 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.255 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.255 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.255 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.255 26069== Address 0x41A6E28 is 88 bytes inside a block of size 104 free'd ==06:20:12:05.255 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.255 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.255 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.255 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.255 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.255 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.255 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.255 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.255 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.255 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.255 26069== ==06:20:12:05.255 26069== 2 errors in context 8 of 41: ==06:20:12:05.255 26069== Invalid write of size 1 ==06:20:12:05.255 26069== at 0x80E505C: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:190) ==06:20:12:05.255 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.255 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.255 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.255 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.255 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.255 26069== Address 0x41A6E29 is 89 bytes inside a block of size 104 free'd ==06:20:12:05.255 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.255 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.256 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.256 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.256 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.256 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.256 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.256 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.256 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.256 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.256 26069== 2009/6/23 Steven Van Ingelgem <st...@va...> > I think this is because the object is deleted, but somehow it is still > reading from it... Can that be? I don't delete threads from anywhere... > > ==06:20:12:05.257 26069== > ==06:20:12:05.257 26069== 2 errors in context 10 of 41: > ==06:20:12:05.257 26069== Invalid read of size 1 > ==06:20:12:05.257 26069== at 0x80DDA93: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:169) > ==06:20:12:05.257 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.257 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.257 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.257 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.257 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.257 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.257 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.257 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.257 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.257 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.257 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.257 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.257 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.257 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.257 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.257 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.257 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.258 26069== > ==06:20:12:05.258 26069== 2 errors in context 11 of 41: > ==06:20:12:05.258 26069== Invalid read of size 1 > ==06:20:12:05.258 26069== at 0x80DDA88: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.258 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.258 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.258 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.258 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.258 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.258 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.258 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.258 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.258 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.258 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.258 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.258 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.258 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.258 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.258 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.258 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.258 26069== > ==06:20:12:05.258 26069== 2 errors in context 12 of 41: > ==06:20:12:05.258 26069== Invalid read of size 1 > ==06:20:12:05.258 26069== at 0x80DDA7D: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() > (ProbePool.cpp:33) > ==06:20:12:05.258 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.259 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.259 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.259 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.259 26069== Address 0x41A6E28 is 88 bytes inside a block of > size 104 free'd > ==06:20:12:05.259 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.259 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.259 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.259 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.259 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.259 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.259 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.259 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.259 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.259 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.259 26069== > ==06:20:12:05.259 26069== 2 errors in context 13 of 41: > ==06:20:12:05.259 26069== Invalid read of size 1 > ==06:20:12:05.259 26069== at 0x80DDA93: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:169) > ==06:20:12:05.259 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.259 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.259 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.259 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.259 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.259 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.260 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.260 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.260 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.260 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.260 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.260 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.260 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.260 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.260 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.260 26069== > ==06:20:12:05.260 26069== 2 errors in context 14 of 41: > ==06:20:12:05.260 26069== Invalid read of size 1 > ==06:20:12:05.260 26069== at 0x80DDA88: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.260 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.260 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.260 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.260 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.260 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.260 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.260 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.260 26069== Address 0x41A6E2A is 90 bytes inside a block of > size 104 free'd > ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.260 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.260 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.260 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.261 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.261 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.261 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.261 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.261 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.261 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.261 26069== > ==06:20:12:05.261 26069== 2 errors in context 15 of 41: > ==06:20:12:05.261 26069== Invalid read of size 1 > ==06:20:12:05.261 26069== at 0x80DDA7D: > dlib::threaded_object::should_stop() const > (threaded_object_extension.cpp:167) > ==06:20:12:05.261 26069== by 0x80D22C5: ProbePoolHelper::thread() > (ProbePool.cpp:46) > ==06:20:12:05.261 26069== by 0x80E5043: > dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) > ==06:20:12:05.261 26069== by 0x80F37CC: void > dlib::dlib_create_new_thread_helper<dlib::threaded_object, > &(dlib::threaded_object::thread_helper())>(void*) > (create_new_thread_extension.h:24) > ==06:20:12:05.261 26069== by 0x80E5171: > dlib::threads_kernel_shared::thread_starter(void*) > (threads_kernel_shared.cpp:231) > ==06:20:12:05.261 26069== by 0x80E5DC8: > dlib::threads_kernel_shared_helpers::thread_starter(void*) > (threads_kernel_2.cpp:39) > ==06:20:12:05.261 26069== by 0x29849A: start_thread (in /lib/ > libpthread-2.5.so) > ==06:20:12:05.261 26069== by 0x21842D: clone (in /lib/libc-2.5.so) > ==06:20:12:05.261 26069== Address 0x41A6E28 is 88 bytes inside a block of > size 104 free'd > ==06:20:12:05.261 26069== at 0x4004CF1: operator delete(void*) > (vg_replace_malloc.c:244) > ==06:20:12:05.261 26069== by 0x80D238A: > ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) > ==06:20:12:05.261 26069== by 0x80D1CE7: > dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) > ==06:20:12:05.261 26069== by 0x80D1D3A: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper> > >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) > ==06:20:12:05.261 26069== by 0x80D1D50: void > std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) > ==06:20:12:05.261 26069== by 0x80D1D7F: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) > ==06:20:12:05.261 26069== by 0x80D1D99: void > std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, > dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< > ProbePoolHelper> >) (stl_construct.h:182) > ==06:20:12:05.262 26069== by 0x80D2020: > std::vector<dlib::shared_ptr<ProbePoolHelper>, > std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() > (stl_vector.h:272) > ==06:20:12:05.262 26069== by 0x80D144E: ProbePool::~ProbePool() > (ProbePool.cpp:68) > ==06:20:12:05.262 26069== by 0x80C3177: main (main.cpp:61) > ==06:20:12:05.262 26069== > > > > > |
|
From: Steven V. I. <st...@va...> - 2009-06-23 06:25:47
|
I think this is because the object is deleted, but somehow it is still reading from it... Can that be? I don't delete threads from anywhere... ==06:20:12:05.257 26069== ==06:20:12:05.257 26069== 2 errors in context 10 of 41: ==06:20:12:05.257 26069== Invalid read of size 1 ==06:20:12:05.257 26069== at 0x80DDA93: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:169) ==06:20:12:05.257 26069== by 0x80D230C: ProbePoolHelper::thread() (ProbePool.cpp:33) ==06:20:12:05.257 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.257 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.257 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.257 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.257 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.257 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.257 26069== Address 0x41A6E2A is 90 bytes inside a block of size 104 free'd ==06:20:12:05.257 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.257 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.257 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.257 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.257 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.257 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.257 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.257 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.257 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.258 26069== ==06:20:12:05.258 26069== 2 errors in context 11 of 41: ==06:20:12:05.258 26069== Invalid read of size 1 ==06:20:12:05.258 26069== at 0x80DDA88: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:167) ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() (ProbePool.cpp:33) ==06:20:12:05.258 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.258 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.258 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.258 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.258 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.258 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.258 26069== Address 0x41A6E2A is 90 bytes inside a block of size 104 free'd ==06:20:12:05.258 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.258 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.258 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.258 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.258 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.258 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.258 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.258 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.258 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.258 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.258 26069== ==06:20:12:05.258 26069== 2 errors in context 12 of 41: ==06:20:12:05.258 26069== Invalid read of size 1 ==06:20:12:05.258 26069== at 0x80DDA7D: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:167) ==06:20:12:05.258 26069== by 0x80D230C: ProbePoolHelper::thread() (ProbePool.cpp:33) ==06:20:12:05.258 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.259 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.259 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.259 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.259 26069== Address 0x41A6E28 is 88 bytes inside a block of size 104 free'd ==06:20:12:05.259 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.259 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.259 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.259 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.259 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.259 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.259 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.259 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.259 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.259 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.259 26069== ==06:20:12:05.259 26069== 2 errors in context 13 of 41: ==06:20:12:05.259 26069== Invalid read of size 1 ==06:20:12:05.259 26069== at 0x80DDA93: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:169) ==06:20:12:05.259 26069== by 0x80D22C5: ProbePoolHelper::thread() (ProbePool.cpp:46) ==06:20:12:05.259 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.259 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.259 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.259 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.259 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.259 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.259 26069== Address 0x41A6E2A is 90 bytes inside a block of size 104 free'd ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.260 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.260 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.260 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.260 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.260 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.260 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.260 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.260 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.260 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.260 26069== ==06:20:12:05.260 26069== 2 errors in context 14 of 41: ==06:20:12:05.260 26069== Invalid read of size 1 ==06:20:12:05.260 26069== at 0x80DDA88: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:167) ==06:20:12:05.260 26069== by 0x80D22C5: ProbePoolHelper::thread() (ProbePool.cpp:46) ==06:20:12:05.260 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.260 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.260 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.260 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.260 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.260 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.260 26069== Address 0x41A6E2A is 90 bytes inside a block of size 104 free'd ==06:20:12:05.260 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.260 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.260 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.260 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.261 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.261 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.261 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.261 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.261 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.261 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.261 26069== ==06:20:12:05.261 26069== 2 errors in context 15 of 41: ==06:20:12:05.261 26069== Invalid read of size 1 ==06:20:12:05.261 26069== at 0x80DDA7D: dlib::threaded_object::should_stop() const (threaded_object_extension.cpp:167) ==06:20:12:05.261 26069== by 0x80D22C5: ProbePoolHelper::thread() (ProbePool.cpp:46) ==06:20:12:05.261 26069== by 0x80E5043: dlib::threaded_object::thread_helper() (threaded_object_extension.cpp:183) ==06:20:12:05.261 26069== by 0x80F37CC: void dlib::dlib_create_new_thread_helper<dlib::threaded_object, &(dlib::threaded_object::thread_helper())>(void*) (create_new_thread_extension.h:24) ==06:20:12:05.261 26069== by 0x80E5171: dlib::threads_kernel_shared::thread_starter(void*) (threads_kernel_shared.cpp:231) ==06:20:12:05.261 26069== by 0x80E5DC8: dlib::threads_kernel_shared_helpers::thread_starter(void*) (threads_kernel_2.cpp:39) ==06:20:12:05.261 26069== by 0x29849A: start_thread (in /lib/ libpthread-2.5.so) ==06:20:12:05.261 26069== by 0x21842D: clone (in /lib/libc-2.5.so) ==06:20:12:05.261 26069== Address 0x41A6E28 is 88 bytes inside a block of size 104 free'd ==06:20:12:05.261 26069== at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244) ==06:20:12:05.261 26069== by 0x80D238A: ProbePoolHelper::~ProbePoolHelper() (ProbePool.cpp:13) ==06:20:12:05.261 26069== by 0x80D1CE7: dlib::shared_ptr<ProbePoolHelper>::~shared_ptr() (shared_ptr.h:187) ==06:20:12:05.261 26069== by 0x80D1D3A: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:107) ==06:20:12:05.261 26069== by 0x80D1D50: void std::__destroy_aux<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, __false_type) (stl_construct.h:122) ==06:20:12:05.261 26069== by 0x80D1D7F: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*>(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*) (stl_construct.h:155) ==06:20:12:05.261 26069== by 0x80D1D99: void std::_Destroy<dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper> >(dlib::shared_ptr<ProbePoolHelper>*, dlib::shared_ptr<ProbePoolHelper>*, std::allocator<dlib::shared_ptr< ProbePoolHelper> >) (stl_construct.h:182) ==06:20:12:05.262 26069== by 0x80D2020: std::vector<dlib::shared_ptr<ProbePoolHelper>, std::allocator<dlib::shared_ptr<ProbePoolHelper> > >::~vector() (stl_vector.h:272) ==06:20:12:05.262 26069== by 0x80D144E: ProbePool::~ProbePool() (ProbePool.cpp:68) ==06:20:12:05.262 26069== by 0x80C3177: main (main.cpp:61) ==06:20:12:05.262 26069== |
|
From: Davis K. <dav...@gm...> - 2009-06-22 15:13:28
|
You can do that using the logger::set_logger_header() function. You can either make your own logger header function which you pass to it or you can use the print_datetime_logger_header() function (which is what it sounds like you are asking for). Cheers, Davis On Mon, Jun 22, 2009 at 10:57 AM, Steven Van Ingelgem <st...@va... > wrote: > Davis, > > > How can I modify the logger output? I don't really like the # of ms since > program start. I prefer to have the current date/time (like "%Y-%m-%d > %H:%M:%S")... > Is there a possibility somewhere? > > > Thanks, > Steven > |
|
From: Davis K. <dav...@us...> - 2009-06-19 01:17:20
|
I just added a set_output_hook() function to the logger object so that you can do this. The new code is in subversion and there is a snapshot also at http://davis.sytes.net/~davis/release/ if you want to try it out. Cheers, Davis On Wed, May 20, 2009 at 10:30 AM, 水波 <ti...@gm...> wrote: > I thought that if the dlib::logger has one interface or hook like these, > will let the matter be simpler. > > bool OnLog( > const std::string& logger_name, > const log_level& l, > const uint64 thread_id, > const std::string& log_content > ); > or > void doLog( > const std::string& logger_name, > const log_level& l, > const uint64 thread_id, > const std::string& log_content, > bool& handled // default false > ); > With this interface,it's possible to custom logger behavior or easy > to store log in database.And then, to analyze log is easier. > > 2009/5/19 Davis King <dav...@us...> > >> Why do you want to change the number of threads in the thread pool? >> Typically I would think you would set it to the number of > > |
|
From: Davis K. <dav...@us...> - 2009-05-25 17:59:09
|
Cool. I just merged in your patch and set it up like this. The changes are in subversion and also up at http://davis.sytes.net/~davis/release if you want to take a look. Cheers, Davis On Sat, May 23, 2009 at 10:23 PM, Miguel Grinberg <mig...@ve...>wrote: > Sure, a timeout on read() works as well. Thanks! > > Miguel > > Davis King wrote: > >> Indeed, that's what dlib::timeout does. >> >> How about I just add the timeout directly to the read() function? It >> sounds like that is all you need. And maybe in the future we can setup >> some kind of nonblocking_connection object with full support for using >> select on multiple connections and all that good stuff. >> Cheers, >> Davis >> >> On Sat, May 23, 2009 at 2:06 PM, Miguel Grinberg <mig...@ve...<mailto: >> mig...@ve...>> wrote: >> >> Well, the problem is not that the call to read blocks, it is that >> it blocks forever. The readable() method I added has a timeout, so >> with that I can control for how long I want to block while waiting >> for data. It is a much cleaner way than using dlib::timeout, which >> if I understand it correctly would close the connection when the >> timeout expires. >> >> Miguel >> >> Davis King wrote: >> >> Yeah, I think you are right about the non-blocking reading. >> Right now the only way to implement a timeout on a read >> operation is to use the dlib::timeout class which is sort of a >> heavyweight solution. So having non-blocking reading seems >> like it would be a nice alternative. >> What do you usually do when you aren't blocking on a call to >> read? You have to be blocking on a call to something else >> right? sleep() maybe? Either that or you are spinning in a >> loop and killing CPU time. >> >> Cheers, >> Davis >> >> On Sat, May 23, 2009 at 2:21 AM, Miguel Grinberg >> <mig...@ve... <mailto:mig...@ve...> >> <mailto:mig...@ve... <mailto:mig...@ve...>>> >> wrote: >> >> Hi Davis, >> >> I guess for the write side this change is more of a >> "ready_to_send" function. A non-blocking operation cannot be >> guaranteed, the only thing you can ensure is that at least >> part of >> your data buffer will get through right away. >> >> I'm only using the non-blocking read function right now, >> that one >> doesn't seem to have any side effects, it seems to me that for >> read with the use of select you can achieve true non-blocking >> behavior. >> >> In my experience non-blocking writing isn't all that common >> anyway, I normally use non-blocking I/O to prevent my >> application >> from blocking while waiting for the other end to send data, but >> when I'm the one sending I don't mind blocking. >> >> Thanks for your email. >> >> Miguel >> >> Davis King wrote: >> >> I have been testing out this patch for a while (on >> windows and >> linux) and trying to think if there are any funny corner >> cases. I also spent a lot of time a few years ago >> trying to >> work something like this into the connection object and >> ended >> up giving up but I forgot why until just now. >> Anyway, I found a problem related to sending data via >> send(). >> The problem is that send() will block, even if >> select() says >> it won't, if you give it a buffer larger than a certain >> value >> (the value depends on your platform and isn't at all >> portable). Linux allows you to set the MSG_DONTWAIT flag >> which fixes the issue but MSG_DONTWAIT isn't a POSIX >> thing and >> so isn't portable to other platforms. See >> >> http://www.opengroup.org/onlinepubs/009695399/functions/send.html >> for example. >> >> I think the only safe way to get this to work is to >> create the >> socket in non-blocking mode to begin with. Then we >> don't have >> to worry about functions blocking when hidden buffer size >> limits are hit. So I think that would mean making a new >> object that explicitly represented a non-blocking socket. >> I'm not in any dire need for non-blocking sockets so I >> probably won't be implementing this any time soon. >> You might also want to check out the asio library >> (http://think-async.com/Asio/). It has a whole lot of >> support >> for varous kinds of networking modes. It is also, in all >> probability, the networking library that will >> eventually make >> it into C++ standard library. So it might be worth >> learning >> just for that reason :) >> >> Cheers, >> Davis >> >> On Fri, Apr 17, 2009 at 7:35 PM, miguelg50 >> <mig...@ve... <mailto:mig...@ve...> >> <mailto:mig...@ve... <mailto:mig...@ve...>> >> <mailto:mig...@ve... >> <mailto:mig...@ve...> <mailto:mig...@ve... >> <mailto:mig...@ve...>>>> >> >> wrote: >> >> Davis, >> >> Attached is the patch for the non-blocking socket >> changes I've >> made. I hope >> it is useful. >> >> Miguel >> >> >> >> >> >> >> >> >> > > |
|
From: Miguel G. <mig...@ve...> - 2009-05-24 02:24:39
|
Sure, a timeout on read() works as well. Thanks! Miguel Davis King wrote: > Indeed, that's what dlib::timeout does. > > How about I just add the timeout directly to the read() function? It > sounds like that is all you need. And maybe in the future we can > setup some kind of nonblocking_connection object with full support for > using select on multiple connections and all that good stuff. > > Cheers, > Davis > > On Sat, May 23, 2009 at 2:06 PM, Miguel Grinberg > <mig...@ve... <mailto:mig...@ve...>> wrote: > > Well, the problem is not that the call to read blocks, it is that > it blocks forever. The readable() method I added has a timeout, so > with that I can control for how long I want to block while waiting > for data. It is a much cleaner way than using dlib::timeout, which > if I understand it correctly would close the connection when the > timeout expires. > > Miguel > > Davis King wrote: > > Yeah, I think you are right about the non-blocking reading. > Right now the only way to implement a timeout on a read > operation is to use the dlib::timeout class which is sort of a > heavyweight solution. So having non-blocking reading seems > like it would be a nice alternative. > What do you usually do when you aren't blocking on a call to > read? You have to be blocking on a call to something else > right? sleep() maybe? Either that or you are spinning in a > loop and killing CPU time. > > Cheers, > Davis > > On Sat, May 23, 2009 at 2:21 AM, Miguel Grinberg > <mig...@ve... <mailto:mig...@ve...> > <mailto:mig...@ve... <mailto:mig...@ve...>>> > wrote: > > Hi Davis, > > I guess for the write side this change is more of a > "ready_to_send" function. A non-blocking operation cannot be > guaranteed, the only thing you can ensure is that at least > part of > your data buffer will get through right away. > > I'm only using the non-blocking read function right now, > that one > doesn't seem to have any side effects, it seems to me that for > read with the use of select you can achieve true non-blocking > behavior. > > In my experience non-blocking writing isn't all that common > anyway, I normally use non-blocking I/O to prevent my > application > from blocking while waiting for the other end to send data, but > when I'm the one sending I don't mind blocking. > > Thanks for your email. > > Miguel > > Davis King wrote: > > I have been testing out this patch for a while (on > windows and > linux) and trying to think if there are any funny corner > cases. I also spent a lot of time a few years ago > trying to > work something like this into the connection object and > ended > up giving up but I forgot why until just now. > Anyway, I found a problem related to sending data via > send(). > The problem is that send() will block, even if > select() says > it won't, if you give it a buffer larger than a certain > value > (the value depends on your platform and isn't at all > portable). Linux allows you to set the MSG_DONTWAIT flag > which fixes the issue but MSG_DONTWAIT isn't a POSIX > thing and > so isn't portable to other platforms. See > > http://www.opengroup.org/onlinepubs/009695399/functions/send.html > for example. > > I think the only safe way to get this to work is to > create the > socket in non-blocking mode to begin with. Then we > don't have > to worry about functions blocking when hidden buffer size > limits are hit. So I think that would mean making a new > object that explicitly represented a non-blocking socket. > I'm not in any dire need for non-blocking sockets so I > probably won't be implementing this any time soon. > You might also want to check out the asio library > (http://think-async.com/Asio/). It has a whole lot of > support > for varous kinds of networking modes. It is also, in all > probability, the networking library that will > eventually make > it into C++ standard library. So it might be worth > learning > just for that reason :) > > Cheers, > Davis > > On Fri, Apr 17, 2009 at 7:35 PM, miguelg50 > <mig...@ve... <mailto:mig...@ve...> > <mailto:mig...@ve... <mailto:mig...@ve...>> > <mailto:mig...@ve... > <mailto:mig...@ve...> <mailto:mig...@ve... > <mailto:mig...@ve...>>>> > > wrote: > > Davis, > > Attached is the patch for the non-blocking socket > changes I've > made. I hope > it is useful. > > Miguel > > > > > > > > |
|
From: Davis K. <dav...@us...> - 2009-05-23 21:33:02
|
Indeed, that's what dlib::timeout does. How about I just add the timeout directly to the read() function? It sounds like that is all you need. And maybe in the future we can setup some kind of nonblocking_connection object with full support for using select on multiple connections and all that good stuff. Cheers, Davis On Sat, May 23, 2009 at 2:06 PM, Miguel Grinberg <mig...@ve...>wrote: > Well, the problem is not that the call to read blocks, it is that it blocks > forever. The readable() method I added has a timeout, so with that I can > control for how long I want to block while waiting for data. It is a much > cleaner way than using dlib::timeout, which if I understand it correctly > would close the connection when the timeout expires. > > Miguel > > Davis King wrote: > >> Yeah, I think you are right about the non-blocking reading. >> Right now the only way to implement a timeout on a read operation is to >> use the dlib::timeout class which is sort of a heavyweight solution. So >> having non-blocking reading seems like it would be a nice alternative. >> What do you usually do when you aren't blocking on a call to read? You >> have to be blocking on a call to something else right? sleep() maybe? >> Either that or you are spinning in a loop and killing CPU time. >> >> Cheers, >> Davis >> >> On Sat, May 23, 2009 at 2:21 AM, Miguel Grinberg <mig...@ve...<mailto: >> mig...@ve...>> wrote: >> >> Hi Davis, >> >> I guess for the write side this change is more of a >> "ready_to_send" function. A non-blocking operation cannot be >> guaranteed, the only thing you can ensure is that at least part of >> your data buffer will get through right away. >> >> I'm only using the non-blocking read function right now, that one >> doesn't seem to have any side effects, it seems to me that for >> read with the use of select you can achieve true non-blocking >> behavior. >> >> In my experience non-blocking writing isn't all that common >> anyway, I normally use non-blocking I/O to prevent my application >> from blocking while waiting for the other end to send data, but >> when I'm the one sending I don't mind blocking. >> >> Thanks for your email. >> >> Miguel >> >> Davis King wrote: >> >> I have been testing out this patch for a while (on windows and >> linux) and trying to think if there are any funny corner >> cases. I also spent a lot of time a few years ago trying to >> work something like this into the connection object and ended >> up giving up but I forgot why until just now. >> Anyway, I found a problem related to sending data via send(). >> The problem is that send() will block, even if select() says >> it won't, if you give it a buffer larger than a certain value >> (the value depends on your platform and isn't at all >> portable). Linux allows you to set the MSG_DONTWAIT flag >> which fixes the issue but MSG_DONTWAIT isn't a POSIX thing and >> so isn't portable to other platforms. See >> http://www.opengroup.org/onlinepubs/009695399/functions/send.html >> for example. >> >> I think the only safe way to get this to work is to create the >> socket in non-blocking mode to begin with. Then we don't have >> to worry about functions blocking when hidden buffer size >> limits are hit. So I think that would mean making a new >> object that explicitly represented a non-blocking socket. >> I'm not in any dire need for non-blocking sockets so I >> probably won't be implementing this any time soon. >> You might also want to check out the asio library >> (http://think-async.com/Asio/). It has a whole lot of support >> for varous kinds of networking modes. It is also, in all >> probability, the networking library that will eventually make >> it into C++ standard library. So it might be worth learning >> just for that reason :) >> >> Cheers, >> Davis >> >> On Fri, Apr 17, 2009 at 7:35 PM, miguelg50 >> <mig...@ve... <mailto:mig...@ve...> >> <mailto:mig...@ve... <mailto:mig...@ve...>>> >> wrote: >> >> Davis, >> >> Attached is the patch for the non-blocking socket changes I've >> made. I hope >> it is useful. >> >> Miguel >> >> >> >> >> >> > > |
|
From: Miguel G. <mig...@ve...> - 2009-05-23 18:06:36
|
Well, the problem is not that the call to read blocks, it is that it blocks forever. The readable() method I added has a timeout, so with that I can control for how long I want to block while waiting for data. It is a much cleaner way than using dlib::timeout, which if I understand it correctly would close the connection when the timeout expires. Miguel Davis King wrote: > Yeah, I think you are right about the non-blocking reading. > > Right now the only way to implement a timeout on a read operation is > to use the dlib::timeout class which is sort of a heavyweight > solution. So having non-blocking reading seems like it would be a > nice alternative. > > What do you usually do when you aren't blocking on a call to read? > You have to be blocking on a call to something else right? sleep() > maybe? Either that or you are spinning in a loop and killing CPU time. > > Cheers, > Davis > > On Sat, May 23, 2009 at 2:21 AM, Miguel Grinberg > <mig...@ve... <mailto:mig...@ve...>> wrote: > > Hi Davis, > > I guess for the write side this change is more of a > "ready_to_send" function. A non-blocking operation cannot be > guaranteed, the only thing you can ensure is that at least part of > your data buffer will get through right away. > > I'm only using the non-blocking read function right now, that one > doesn't seem to have any side effects, it seems to me that for > read with the use of select you can achieve true non-blocking > behavior. > > In my experience non-blocking writing isn't all that common > anyway, I normally use non-blocking I/O to prevent my application > from blocking while waiting for the other end to send data, but > when I'm the one sending I don't mind blocking. > > Thanks for your email. > > Miguel > > Davis King wrote: > > I have been testing out this patch for a while (on windows and > linux) and trying to think if there are any funny corner > cases. I also spent a lot of time a few years ago trying to > work something like this into the connection object and ended > up giving up but I forgot why until just now. > Anyway, I found a problem related to sending data via send(). > The problem is that send() will block, even if select() says > it won't, if you give it a buffer larger than a certain value > (the value depends on your platform and isn't at all > portable). Linux allows you to set the MSG_DONTWAIT flag > which fixes the issue but MSG_DONTWAIT isn't a POSIX thing and > so isn't portable to other platforms. > See > http://www.opengroup.org/onlinepubs/009695399/functions/send.html > for example. > > I think the only safe way to get this to work is to create the > socket in non-blocking mode to begin with. Then we don't have > to worry about functions blocking when hidden buffer size > limits are hit. So I think that would mean making a new > object that explicitly represented a non-blocking socket. > I'm not in any dire need for non-blocking sockets so I > probably won't be implementing this any time soon. > You might also want to check out the asio library > (http://think-async.com/Asio/). It has a whole lot of support > for varous kinds of networking modes. It is also, in all > probability, the networking library that will eventually make > it into C++ standard library. So it might be worth learning > just for that reason :) > > Cheers, > Davis > > On Fri, Apr 17, 2009 at 7:35 PM, miguelg50 > <mig...@ve... <mailto:mig...@ve...> > <mailto:mig...@ve... <mailto:mig...@ve...>>> > wrote: > > Davis, > > Attached is the patch for the non-blocking socket changes I've > made. I hope > it is useful. > > Miguel > > > > > |
9 messages has been excluded from this view by a project administrator.
