It is not just luck. I had an error in eo_unref, took the obj id, set a breakpoint on some function of eo with that id and reran the program.
On 04/24/2013 03:44 PM, Tom Hacohen wrote: > On 24/04/13 13:26, daniel.za...@samsung.com wrote: >> By the way, an advantage of this feature is that you can easily put a >> condition on a breakpoint in gdb by using the "pointer" of the previous >> run. It works on some condition, like the scenario must be the same and >> you have to hope that there is not too much timers in the background. >> But if you have these conditions (in elementary_tests, it is easy :-)), >> you can do that. For example, if someone calls eo_data_get on an object >> after it has been removed, and you want to know when it has been >> removed, just break on eo_del with the object id and run it. >> >> I know, it's a dumb example, but the concept is interesting. > > As you've mentioned, it's not really constant. You can't really rely > on that. :) It's better to have things that don't depend on luck. > > -- > Tom. > > ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
