| 00:09.57 | brlcad | poolio: yes, profile (gprof), valgrind, write isolated unit test cases (that just test ONE function), and then polish your code |
| 00:10.34 | brlcad | those four steps should reveal at least a few issues if not many (particularly the isolated unit tests and valgrind) |
| 00:14.42 | poolio | Well, I don't think there is really an issue. I can't see anything is wrong. Speed is something that I could look at with profiling, but as far as I can see it's working fine, the algorithm just isn't doing too great |
| 00:15.02 | brlcad | it's not to find an issues, that's just due diligence on any code |
| 00:15.28 | poolio | Wait, so you're saying I should profile anyway? |
| 00:15.37 | brlcad | all code could ideally have all four of those cases written.. and they very OFTEN do uncover entirely unexpected issues |
| 00:15.41 | brlcad | yep |
| 00:15.51 | poolio | alright. I'll get on that. |
| 00:16.58 | brlcad | plus it's just good a exercise to get proficient in, particularly if you've never done it |
| 00:17.24 | brlcad | the configure option --enable-profile will turn on the gprof profile flag |
| 00:17.42 | brlcad | use that with debugging symbols enabled |
| 00:18.21 | brlcad | then run gprof and your program name in the dir with the gmon.out log and it'll generate a report -- see the web for some tutorials, manpage for docs, etc .. there are a lot of options |
| 00:18.52 | brlcad | undoubtedly, it will be spending a ton of time in the ray evaluation routines as you're very much cpu-bound, but there could be some surprises |
| 00:18.57 | poolio | alrighty. there's still some code clean up that I may do first, but that sounds good. |
| 00:19.20 | brlcad | i'd suggest running valgrind before doing gprof |
| 00:19.27 | poolio | but I mean shouldn't I still be going for getting better results out of the GA? |
| 00:19.46 | brlcad | this will be a good "breather" for a day or two :) |
| 00:19.49 | poolio | brlcad: yeah the issue with valgrind is it seperates the reports with each thread |
| 00:20.00 | poolio | heh, dont have time for a breather :) |
| 00:20.05 | brlcad | so run it single threaded first :) |
| 00:20.34 | brlcad | there's a few things it'll likely report in librt itself that don't clean up on exit, and those are known/can be ignored |
| 00:20.53 | poolio | k |
| 00:21.11 | brlcad | otherwise it should be nearly a clean/empty report |
| 00:22.09 | brlcad | there should be zero "definitely lost" leaks |
| 00:22.21 | brlcad | even in system libs |
| 00:23.49 | poolio | ==14776== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1) |
| 00:37.24 | ``Erik | what's left on the 7.10.2 checklist, yo? |
| 00:54.59 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 01:19.12 | louipc | is there a point where you'll check that it builds nicely before release? |
| 01:20.29 | louipc | I'd like to check if it works on archlinux, last time it didn't work so I didn't update the pkg. I didn't feel like patching it from heh. :/ |
| 01:47.59 | poolio | brlcad: I don't think my timer is fast enough...? |
| 04:19.07 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 08:01.27 | *** join/#brlcad CIA-29 (n=CIA@208.69.182.149) |
| 08:40.43 | *** join/#brlcad Laniakea (i=clock@217-162-228-71.dclient.hispeed.ch) |
| 09:34.20 | Laniakea | msg -lugs tarzeau do you wear contact lenses? |
| 10:00.54 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 10:01.43 | Laniakea | omg |
| 10:11.55 | poolio | morning? |
| 10:11.56 | tarzeau | Laniakea: sometimes? |
| 10:12.03 | tarzeau | Laniakea: you got an irc problem? |
| 10:13.53 | Laniakea | tarzeau: no I left out the / |
| 10:14.17 | Laniakea | tarzeau: see query |
| 10:14.22 | Laniakea | (on lugs) |
| 10:26.00 | Laniakea | tarzeau: do you see my query? You are not responding |
| 10:26.12 | tarzeau | wait |
| 11:30.31 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-076-163.pools.arcor-ip.net) |
| 11:44.03 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 11:44.43 | *** join/#brlcad AchiestDragon (n=david@whipy.demon.co.uk) |
| 11:57.50 | *** join/#brlcad thing0 (n=ric@210-84-29-115.dyn.iinet.net.au) |
| 11:59.38 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-076-163.pools.arcor-ip.net) |
| 12:52.15 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-076-163.pools.arcor-ip.net) |
| 13:06.58 | *** part/#brlcad thing0 (n=ric@210-84-29-115.dyn.iinet.net.au) |
| 13:37.01 | ``Erik | louipc: the last step before release is to take the candidate tarball to a slew of os/arch combos and make sure it compiles, runs benchmark, and does a fistful of things in mged... which I *THINK* is what brlcad is sorta doing now |
| 14:02.51 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-076-163.pools.arcor-ip.net) |
| 14:04.09 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) |
| 14:27.06 | CIA-29 | BRL-CAD: 03erikgreenwald * 10brlcad/src/libtclcad/ (Makefile.am tkCanvBezier.c): actually remove tkCanvBezier.c as it's no longer used |
| 14:45.56 | *** join/#brlcad poolio (n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
| 15:57.48 | poolio | brlcad: is there a way to identify what data structure is eating away at the memory? |
| 15:58.05 | poolio | Like I know I have a memory leak somewhere I'm just having a hard time finding it by hand |
| 16:02.17 | brlcad | depends on the nature of the leak -- if it is a true leak, valgrind should have found it |
| 16:03.04 | brlcad | what was the rest of valgrind's report -- errors aren't the only part |
| 16:05.14 | poolio | memcheck whines about stuff internal to librt |
| 16:05.45 | poolio | Oh woah, it changed since the last time I ran it |
| 16:06.30 | poolio | hmm. I have a bunch of definitely lost bytes :\ |
| 16:15.56 | ``Erik | if valgrind and boehm don't find them, they're still reachable by something in the frame stack |
| 16:16.57 | poolio | well valgrind found some |
| 16:17.03 | poolio | but it doesn't make senes |
| 16:17.04 | poolio | e |
| 16:19.37 | poolio | ``Erik: http://rafb.net/p/eCHfmb31.html |
| 16:20.26 | brlcad | might not make sense but i've yet to see valgrid be wrong :) |
| 16:20.26 | poolio | It's saying that rt_init_resource is leaking, but I rt_clean the resources for sure... |
| 16:20.58 | poolio | Yeah yeah |
| 16:20.58 | brlcad | that one is known |
| 16:21.08 | poolio | alright, so that's all normal? |
| 16:21.10 | brlcad | the ptbl ones can be ignored |
| 16:21.39 | brlcad | there is no counterpart to rt_init_resource |
| 16:21.47 | brlcad | so items it allocated are never freed |
| 16:21.56 | poolio | Well that's a big issue |
| 16:22.09 | poolio | Because I re-allocate resources every time I raytrace a new individual |
| 16:22.25 | poolio | what about rt_clean_resource() ? |
| 16:22.34 | brlcad | that should be fine, it releases if you call init again |
| 16:22.53 | poolio | so I don't need to run rt_clean_resources() ? |
| 16:23.50 | brlcad | no, you should |
| 16:24.31 | poolio | Ok, and what about the rt_gettree one? |
| 16:24.58 | brlcad | there could be a leak in rt_clean_resources(), I'll look into it |
| 16:25.07 | brlcad | that's one that shouldn't be there |
| 16:25.36 | poolio | I'm calling it so much, the leaks just get bigger and bigger |
| 16:25.48 | brlcad | you've not freed the item from rt_gettree() I believe |
| 16:27.29 | poolio | Well, I rt_gettree() into some rtip, and I rt_free_rti() that rtip. So shouldn't that take care of it? |
| 16:28.23 | poolio | brlcad: and this? http://rafb.net/p/vhqFb112.html |
| 16:28.50 | brlcad | now that's a huge leak |
| 16:28.56 | poolio | shouldn't rt_free_rti() take care of that too? |
| 16:29.52 | poolio | I feel like there's something I need to do with the rtip besides rt_free_rti() |
| 16:29.58 | brlcad | in general, no -- rt_free_rti only free's the rti itself, not objects the rti holds |
| 16:30.16 | brlcad | as there can be multiple instances and other issues at play |
| 16:31.01 | poolio | ah alright. So I need to somehow free the structures rt_gettree() creates as well as rt_prep() ? |
| 16:32.42 | brlcad | don't know for sure for these two cases, so I'm looking -- you take the big one, i'll take the little one :) |
| 16:33.38 | poolio | alrighty |
| 16:33.42 | brlcad | it could be a librt leak with certain calling order or some free not being called that your code needs to be doing, hard to say without tracing the leak |
| 16:34.11 | brlcad | make no assumptions, just follow the memory and read the code that relates to it |
| 16:34.25 | poolio | k |
| 16:37.23 | brlcad | er, are you used CVS head? |
| 16:37.34 | poolio | yeah |
| 16:37.39 | brlcad | hmm.. my line numbers aren't matching yours |
| 16:37.56 | poolio | Hmm, haven't updated for a little while |
| 16:38.06 | poolio | guess I can do that |
| 16:38.30 | brlcad | let me know if db_tree.c updates |
| 16:40.12 | brlcad | louipc: I've got clean builds so feel free to test and let me know if you have build issues on your end |
| 16:41.03 | brlcad | ``Erik: i've not got a solaris on hand if you want to test them out |
| 16:41.31 | poolio | brlcad: yeah it changed |
| 16:41.52 | poolio | brlcad: Ah, I think it's that I hadn't updated since you changed the copyright comments last week |
| 16:42.06 | brlcad | ahh, okay |
| 16:42.15 | brlcad | that sounds about right offset-wise |
| 16:42.27 | brlcad | new report would be good to see |
| 16:43.40 | poolio | ah wait |
| 16:43.46 | poolio | I need to recompile dont I |
| 16:47.29 | CIA-29 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/ (fitness.c population.c population.h): more mutation support and cosmetics |
| 16:47.59 | brlcad | yup |
| 16:48.31 | poolio | this is gonna take a while :) |
| 16:51.27 | poolio | grargh what did I break? |
| 16:51.28 | poolio | make: *** No rule to make target `m4/restore.m4', needed by `Makefile.in'. Stop. |
| 16:59.02 | poolio | fixed. |
| 16:59.12 | poolio | brlcad: even with rt_clean() I get the memory leaks |
| 16:59.45 | poolio | Which doesn' tmake sense, it looks like rt_clean() frees _all_ the dynamic structures inside of the rtip. |
| 17:03.08 | Maloeran | Valgrind, boehm... Personally, I found that the best tool to investigate memory leaks is a wrapper around malloc/free/realloc |
| 17:05.15 | Maloeran | BRL-CAD of course has an interface on top of these, but I haven't looked if it can be used to trace leaks |
| 17:08.56 | Maloeran | ( The pseudo-function to get addresses of calling functions, useful for such debugging, is a GCC extension though ) |
| 17:20.03 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128565171.dsl.bell.ca) |
| 17:20.46 | ``Erik | boehm is a wrapper that stubs in place of malloc/free/realloc/calloc |
| 17:24.04 | brlcad | libbu does have it's own memory bounds checking that works pretty well |
| 17:24.41 | ``Erik | bounds, yes, but does it retain alloc lists and look for 'forgotten' bits? |
| 17:25.09 | brlcad | i tend to prefer valgrind's even over the *alloc/free wrappers though as it generally does a much better job and often detects things that other approaches won't/can't |
| 17:25.49 | ``Erik | valgrind seems pretty married to leenewx, though |
| 17:26.00 | ``Erik | efence, boehm, ccmalloc, dmalloc... those're pretty portable |
| 17:28.43 | brlcad | sushi:~/brlcad morrison$ ./a.out 300120 malloc 20 alloc 300128 free free |
| 17:28.46 | brlcad | ERROR bu_free(x300128, free) pointer bad, or not allocated with bu_malloc! Ignored. |
| 17:29.27 | ``Erik | ah, so bu keeps its own malloc info ontop of the system malloc info |
| 17:29.39 | ``Erik | *ponder* |
| 17:30.01 | ``Erik | free(bu_malloc()-bumallocstructsize); hehehehe |
| 17:30.13 | brlcad | http://pastebin.bzflag.bz/m2661afe4 |
| 17:31.50 | ``Erik | <-- gonna build sunos 5.8 using gnu toolchain first, then if that works, try sunwpro |
| 17:32.06 | brlcad | sounds good, what I usually do too |
| 17:32.26 | brlcad | cause if sunwpro doesn't work, not a big deal .. so long as one of the two does easily |
| 17:33.03 | brlcad | and if it just requires a few tweaks, it can always be annotated in doc/README.Solaris |
| 17:34.27 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/castle.png |
| 17:34.30 | IriX64 | :) |
| 17:34.57 | ``Erik | now back in the day, it was a beefy machine... I must be gettin' spoiled, dual 450mhz usparcIIi just seems sssssooooooo ssssssllllllooooooowwwwwwww |
| 17:35.01 | brlcad | the reason valgrind tends to do better than the wrappers is why it's (unfortunately) linux-specific .. performance counters and other low-level issue |
| 17:35.09 | ``Erik | *nod* |
| 17:35.13 | ``Erik | um |
| 17:35.19 | ``Erik | there's one in chud, right? |
| 17:35.27 | ``Erik | not bigtop, um, ... hrm, not saturn I don't think |
| 17:35.30 | brlcad | yeah, it's not too shabby either |
| 17:35.39 | ``Erik | the frankenstein one? |
| 17:35.44 | brlcad | yeah, something like that |
| 17:35.48 | brlcad | two of them actually |
| 17:35.54 | brlcad | one that watches cocoa memory allocations |
| 17:36.00 | brlcad | another that watches all allocations |
| 17:36.02 | ``Erik | <-- has used shark and the ogl profiler, not the others really |
| 17:36.11 | ``Erik | and shark usually from the command line |
| 17:36.17 | brlcad | i've only used it a couple times to notice that it was pretty cool |
| 17:36.28 | brlcad | shark from the command line .. o.O |
| 17:36.30 | ``Erik | shark -i ./myprog ; open *mshark |
| 17:36.36 | brlcad | ah, heh |
| 17:37.11 | poolio | brlcad: any luck? |
| 17:37.41 | brlcad | poolio: was waiting on the new report, or did I miss it? |
| 17:37.52 | poolio | hehe, it's on the way, one sec |
| 17:37.55 | brlcad | so line numbers match up |
| 17:37.59 | poolio | yeah sorry |
| 17:38.07 | poolio | make just finished :\ |
| 17:38.09 | brlcad | pretty sure I see the offsets, but I'd rather not guess |
| 17:41.19 | poolio | rawr! I set the wrong prefix and now I have to rebuild. d'oh |
| 17:42.04 | brlcad | hehe |
| 17:42.09 | brlcad | you don't have to install |
| 17:42.16 | brlcad | you can run in place |
| 17:42.42 | brlcad | just have to be sure to wrap correctly so it doesn't pick up installed libs |
| 17:44.09 | poolio | yeah but I already uninstalled previous |
| 17:44.18 | poolio | and I'd like to have it installed |
| 17:44.28 | poolio | so I'll just do some more code clea up |
| 17:45.45 | brlcad | gah, silly system doesn't have a functional 64-bit libX11, but *does* have functional 64-bit libGL |
| 17:45.56 | brlcad | that's really fscked up |
| 17:46.53 | ``Erik | O.o |
| 17:46.54 | poolio | can 64bit libGL even function without a 64bit X11? |
| 17:47.09 | ``Erik | if it has another display path, sure |
| 17:52.09 | ``Erik | hah |
| 17:52.15 | ``Erik | "Frist Post!!!11eleven!!!1" |
| 17:54.33 | brlcad | hm, probably just need to make the OGL interface check for both ogl and x11 since it's really x11-specific |
| 17:56.26 | poolio | ahhhhhhhhhhhh |
| 17:56.30 | poolio | my laptops at 83C |
| 17:56.35 | poolio | my legs burn. |
| 17:59.37 | ``Erik | man, that pastebin sucks, it doesn't have syntax highlighting for uh.. uhhhhh.... uhhhhhhhh.... erlang! |
| 17:59.50 | poolio | haha |
| 17:59.51 | ``Erik | (damn that's a lot of highlighting options) |
| 18:00.24 | brlcad | heh |
| 18:00.32 | poolio | brlcad: http://rafb.net/p/w7nvet33.html |
| 18:02.19 | brlcad | thx |
| 18:02.29 | ``Erik | hum, no captcha, wonder how long before it starts seeing spam |
| 18:03.24 | brlcad | yeah figured id just see how long it takes |
| 18:16.56 | ``Erik | into liboptical on solaris with the gnu chain |
| 18:35.58 | poolio | brlcad: I really fail to see why when using rt_clean() there's still a memory leak according to valgrind |
| 18:59.41 | poolio | brlcad: it's also giving me a lot of whining about unitialized values that are for sure initialized |
| 19:00.50 | brlcad | example of one? |
| 19:01.48 | poolio | ==20025== Conditional jump or move depends on uninitialised value(s) |
| 19:01.48 | poolio | ==20025== at 0x491F397: __printf_fp (in /lib/i686/cmov/libc-2.5.so) |
| 19:01.55 | poolio | ... |
| 19:02.07 | poolio | ==20025== by 0x8049578: main (beset.c:170) |
| 19:02.47 | poolio | And 27 more of those same contexts |
| 19:03.12 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/7.10.1.png :) |
| 19:03.28 | poolio | brlcad: Can I just pastebin the whole output? |
| 19:03.30 | ``Erik | that smells like gnu suckism |
| 19:03.37 | brlcad | poolio: yes please |
| 19:04.25 | poolio | brlcad: http://rafb.net/p/JlQa3L28.html |
| 19:05.42 | poolio | All of the still reachable blocks are leaked I think |
| 19:10.59 | poolio | Alright, but there's still massive memory leaks somewhere |
| 19:11.16 | poolio | I think the amount of memory leaked is proportional to the population size |
| 19:11.20 | poolio | that doesn't help much though |
| 19:12.06 | ``Erik | line 556 seems to be the biggy |
| 19:12.47 | poolio | You mean 566? |
| 19:12.55 | poolio | brlcad said 556 was known |
| 19:12.57 | ``Erik | yes, sorry |
| 19:13.07 | ``Erik | the gettree stuff |
| 19:13.12 | poolio | yeah |
| 19:13.20 | poolio | shouldn't rt_clean() properly free that stuff? it looked like it did |
| 19:14.07 | ``Erik | man, solaris is wigging out my nfs server here, heh |
| 19:15.50 | ``Erik | huh, why is it count+1? ( |
| 19:16.41 | poolio | where? |
| 19:18.49 | *** join/#brlcad dtidrow (n=dtidrow@host131.objectsciences.com) |
| 19:19.02 | poolio | ``Erik: oh, it includes the current node as part of the count so that it plays nicely with db_count_tree_nodes |
| 19:19.24 | ``Erik | ah |
| 19:19.58 | poolio | ``Erik: were you referencing the return 1+n1+n2? |
| 19:21.28 | ``Erik | src/librt/tree.c:233 :) |
| 19:22.06 | poolio | aha! so that's never being free'd? |
| 19:22.37 | ``Erik | prep has some free's around there, mebbe it's missing those cases |
| 19:23.53 | ``Erik | are you calling rt_clean() or rt_del_regtree() ? |
| 19:24.01 | poolio | rt_clean() |
| 19:24.03 | ``Erik | hrm, ye syou are |
| 19:24.45 | ``Erik | librt/prep.c:891 should be taking care of that :/ |
| 19:24.47 | *** join/#brlcad Laniakea (i=clock@217-162-228-71.dclient.hispeed.ch) |
| 19:26.42 | ``Erik | ahhh, the +1 is to dump in a null terminator |
| 19:28.00 | ``Erik | hummmm |
| 19:28.55 | ``Erik | you might hack up librt, have a static counter initialized to zero, inc it in tree.c and dec it in prep.c and after the rt_clean, see what that # is, then set it to 0 if you'r egoing to make another pass? |
| 19:29.02 | poolio | But still, try running the program, it goes crazy with memory, talking a couple hundred megs |
| 19:29.37 | poolio | ``Erik: hmm worth a shot, I'll have a go |
| 19:29.38 | ``Erik | to see if you're alloc'ing different amounts? it may be that you get a failed alloc in the middle of the alloc loop, and the dealloc stops at the fail instead of the end? |
| 19:31.13 | ``Erik | that's only 650k, it lists 420 megs as still reachable at the end |
| 19:31.20 | ``Erik | heh, accidently msg'd that to brlcad |
| 19:33.39 | poolio | yeah, the 420megs it's what's messed up |
| 19:33.42 | poolio | let me re-run valgrind |
| 19:33.57 | ``Erik | if it's reachable, valgrind won't magically find it |
| 19:34.05 | ``Erik | I mean, you grok what it means, right? |
| 19:36.29 | poolio | grok? |
| 19:38.10 | ``Erik | understand... really well... |
| 19:39.46 | poolio | reachable means there's still a pointer to it but it wasn't freed at exit, right? |
| 19:41.59 | poolio | brlcad/``Erik: it looks like the big memory leak is also related to the bu_ptbl_init |
| 19:49.46 | ``Erik | well, it's free'd at exit() (or, rather, _exit() or whatever exit() calls) |
| 19:50.15 | poolio | yeah the issue is it fills up my memory during run-time and I need to free it before exit() |
| 19:50.20 | ``Erik | but it means that there is still a legitimate way to get to that allocated data via the current stack, globals, or statics |
| 19:50.33 | ``Erik | I'd hope you're not using globals or statics |
| 19:50.46 | poolio | mmmmmaayyyyyyybeeeee |
| 19:50.49 | ``Erik | I thought you had to free it between iterations |
| 19:50.57 | poolio | free what? |
| 19:51.02 | poolio | Well yes |
| 19:51.06 | poolio | that'd be true, during iterations |
| 19:51.07 | ``Erik | the mountains of iteration specific data? :) |
| 19:51.10 | poolio | *in-between as you said |
| 19:51.31 | ``Erik | having reachable data at exit() isn't a bad thing |
| 19:51.52 | ``Erik | no modern OS has system leaks from os space anymore, I think an early win95 was the last to do that |
| 19:51.52 | poolio | I understand, but I have _too much_ reachable data at exit() |
| 19:52.24 | ``Erik | is it building up over iterations? like from not freeing iteration specific stuff? |
| 19:53.07 | poolio | Seems like it |
| 19:53.23 | poolio | The longer it runs the greater the memory used |
| 19:53.39 | poolio | And the amount of data the program should be using shouldn't be growing from iteration to iteratin |
| 19:53.44 | ``Erik | the results you posted are from a single iteration? |
| 19:53.49 | poolio | no |
| 19:53.52 | poolio | I think there were like 10 |
| 19:54.04 | poolio | I need to go help jump my mom's car, I'll be back in a bit. |
| 20:13.22 | poolio | k, i'm back |
| 20:13.29 | poolio | brlcad: so any ideas? |
| 20:19.13 | brlcad | is pop->parent[0] the best or worst after sorting |
| 20:19.44 | poolio | brlcad: worst |
| 20:20.06 | brlcad | k |
| 20:21.26 | ``Erik | the globals in population.c would be my best guess for growth at this moment... |
| 20:21.41 | poolio | ``Erik: Yeah...but they're just pointers |
| 20:21.59 | poolio | I use them when searching for individuals to crossover or mutate |
| 20:22.13 | ``Erik | ... pointers are what you're looking for, dude :D |
| 20:22.27 | poolio | well they're pointers to things that are handled elsewhere |
| 20:23.04 | ``Erik | mebbe write some quick recursive 'count' functions for 'em to see the size, and print those values between iterations? |
| 20:23.15 | ``Erik | or null them out between iterations so valgrind can give you better info |
| 20:24.57 | poolio | Yeah that was a really nasty solution there.. |
| 20:25.12 | poolio | I think when I came up with it, it was just going to be temporary |
| 20:25.26 | poolio | but I don't see a better way other than passing it as an argument |
| 20:25.28 | ``Erik | heh |
| 20:27.05 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/beset/beset.c: initialize some vars |
| 20:35.18 | ``Erik | bah fek |
| 20:35.21 | poolio | brlcad: you fixed the comments, but just FYI the user passes a number and that number is treated as a percentage. So it's keep upper n%, but internally I store it as keep upper n where n != n% |
| 20:35.53 | brlcad | k |
| 20:36.38 | poolio | brlcad: so it's a good practice to initalize my variables even if I know they will not be used uninitialized? |
| 20:37.58 | brlcad | yes |
| 20:38.12 | ``Erik | gcc's warnings will usually flag that situation |
| 20:38.26 | ``Erik | it's good practice to have your CFLAGS include something like -W -Wall -Werror -ansi -pedantic |
| 20:38.27 | ``Erik | :) |
| 20:38.28 | poolio | yeah I test with -Wall as well as a few others |
| 20:38.33 | poolio | ``Erik: :-) |
| 20:38.46 | poolio | sometimes I hate -pedantic though... |
| 20:38.55 | ``Erik | yeah, it's so... pedantic |
| 20:39.29 | brlcad | it's generally good practice as someone down the road might not necessarily be using the same compiler, same conditions, or even worse as the code changes over the years |
| 20:39.46 | poolio | lies! it shall never change ;) |
| 20:40.12 | brlcad | someone edits the code in a couple years (maybe even yourself) and those same assumptions that "some intermediate call" happened to initialize it may no longer hold |
| 20:40.23 | poolio | true true. |
| 20:40.27 | ``Erik | code that never changes generally does so because no one ever uses it... |
| 20:40.35 | ``Erik | I mean, the freakin' LANGUAGE changes |
| 20:40.47 | brlcad | sure it's a problem down the road, but it's easy enough to just initialize, makes debugging easier too as they're in a known state at the start of the stack |
| 20:42.24 | poolio | ==21574== 15,531,368 (74,128 direct, 15,457,240 indirect) bytes in 31 blocks are definitely lost in loss record 10 of 10 |
| 20:42.28 | poolio | ==21574== at 0x40227EF: calloc (vg_replace_malloc.c:279) |
| 20:42.30 | poolio | ==21574== by 0x4759652: bu_alloc (malloc.c:284) |
| 20:42.33 | poolio | ==21574== by 0x4760078: bu_ptbl_init (ptbl.c:77) |
| 20:42.35 | poolio | ==21574== by 0x42453BD: rt_init_resource (prep.c:648 |
| 20:43.28 | brlcad | one step at a time |
| 20:43.29 | poolio | Goes up ~1mb/s |
| 20:43.35 | poolio | :) |
| 20:43.46 | brlcad | did the printf's go away? |
| 20:44.14 | poolio | no. |
| 20:44.35 | brlcad | so there's still something there, I'm just not seeing it |
| 20:44.44 | poolio | something where? in my stuff? |
| 20:44.53 | brlcad | if it was just some glibc issue, it'd be on other printf's |
| 20:45.18 | brlcad | it's on a specific one |
| 20:45.18 | poolio | true |
| 20:45.23 | poolio | it could be possible it is uninitialized |
| 20:45.23 | brlcad | that's valgrind giving you a hint |
| 20:45.28 | poolio | but the program outputs reasonable results |
| 20:49.02 | poolio | eek. 82C. (doing a larger run |
| 20:49.03 | poolio | ) |
| 20:50.58 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/beset/ (beset.c beset.h population.c population.h): no need to malloc a single struct once, just use it |
| 20:52.04 | poolio | fstate? |
| 20:52.54 | brlcad | that's another one |
| 20:52.58 | poolio | brlcad: longer run: http://rafb.net/p/JWdT8589.html |
| 20:57.32 | CIA-29 | BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/population.c: some documentation. re-initialize global vars every iteration. |
| 20:58.42 | poolio | brlcad: are you dealing with fstate? I can do that if you want |
| 21:00.56 | brlcad | go for it |
| 21:01.07 | poolio | k |
| 21:05.16 | poolio | eek I broke something. |
| 21:07.57 | poolio | brlcad: going to pick up car, back in 10 |
| 21:08.11 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/gtools/beset/ (beset.c population.c): quell several warnings |
| 21:08.14 | brlcad | be sure to update, I think I missed some parens on that first update |
| 21:08.18 | brlcad | cya |
| 21:20.06 | poolio | <PROTECTED> |
| 21:21.56 | *** join/#brlcad b0ef (n=b0ef@062016141081.customer.alfanett.no) |
| 21:42.30 | poolio | Bad magic number in re_solid_btiv list |
| 23:13.53 | brlcad | poolio: are you compiled optimized or debug? |
| 23:28.17 | brlcad | some big issue with your usage of the resource structure, curious to see how things look after refactoring fstate |
| 23:28.45 | *** join/#brlcad Twingy (n=justin@74.92.144.217) |
