00:14.59 |
poolio |
brlcad: ah crud. I thought I committed fstate,
I didn't, d'oh. one sec. |
00:15.15 |
poolio |
forgot to put in password. d'oh. |
00:15.53 |
CIA-29 |
BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/
(beset.c fitness.c population.c fitness.h): fixed some bugs
recently introduced. fstate no longer malloc'd |
00:17.35 |
poolio |
brlcad: hmm. I think I'm actually compiled
optimized. I'm guessing that's bad? |
00:34.11 |
brlcad |
yeah, makes debugging a lot harder |
00:34.19 |
brlcad |
particularly because of inlining |
00:34.37 |
brlcad |
otherwise valgrind is saying you've got stack
corruption |
00:35.09 |
poolio |
alright, so enable debugging when I
build? |
00:39.53 |
poolio |
brlcad: when I enabled debug nothing
changed... I guess it was already enabled? |
00:41.39 |
brlcad |
debug is enabled by default |
00:41.49 |
brlcad |
there is that summary at the end, it tells you
what you have :) |
00:41.56 |
poolio |
yeah yeah :P |
00:42.00 |
brlcad |
it's also in your config.log near the
end |
00:42.10 |
poolio |
So debug is enabled, as well as
optimized |
00:42.32 |
brlcad |
so disable-optimized |
00:42.58 |
brlcad |
or keep a separate tree |
00:43.07 |
brlcad |
since it takes your box a while to
recompile |
00:43.18 |
brlcad |
and you probably want optimized for the test
runs |
00:44.51 |
poolio |
ugh :\ |
00:45.44 |
poolio |
brlcad: k, ill copy the directory and build
without optimized, then get back to you when that's done. |
00:46.24 |
brlcad |
see ya in an hour :) |
00:53.36 |
louipc |
hmm |
00:57.04 |
louipc |
when I try to display spkr.s from radio.g mged
exits |
00:58.25 |
brlcad |
your radio.g that you made
presumably? |
00:59.44 |
louipc |
oh yeah I guess I must have made it long ago
from the tutorial |
01:00.01 |
louipc |
actually it's not specific to that file I
tried something else |
01:02.08 |
poolio |
brlcad: my laptop is melting. :( |
01:02.44 |
brlcad |
louipc: can you display anything? |
01:02.51 |
brlcad |
poolio: how about a fan? :) |
01:03.18 |
brlcad |
my old laptop used to get so hot, I kept a
small fan blowing on it all the time |
01:03.58 |
poolio |
brlcad: hmm. where? the underside? |
01:04.22 |
louipc |
brlcad: yeah I was able to display the antenna
and then I tried the spkr then it exited I will try in classic
mode |
01:05.42 |
brlcad |
poolio: no, just blowing across the keys is
often enough to strip away the heat |
01:06.00 |
brlcad |
takes a few minutes of course, but it does the
trick |
01:06.32 |
brlcad |
louipc: cool, I suspect it's crashing for some
reason -- if you can reproduce it in classic, try doing it through
gdb in classic |
01:06.57 |
poolio |
brlcad: not bad. 13 minutes to
compile. |
01:10.28 |
poolio |
brlcad: http://rafb.net/p/GdkYhX91.html |
01:10.56 |
louipc |
yep same stuff. classic at least tells me
'Illegal Instruction' before quitting |
01:11.20 |
brlcad |
poolio: did you leave off all the preceeding
or was that everything? |
01:11.48 |
poolio |
brlcad: I left off preceeding |
01:11.54 |
poolio |
brlcad: here's with --show-reachable also
http://rafb.net/p/IgdRHb93.html |
01:12.10 |
poolio |
Note: all the previous errors happen before
the main generation loop |
01:12.28 |
brlcad |
i mean like the printf stuff |
01:12.36 |
poolio |
yeah one sec |
01:12.39 |
poolio |
that shows up before the program
output |
01:12.50 |
brlcad |
that's okay, it's still saying there's a
potential problem |
01:13.06 |
poolio |
lemme just copy it all :) |
01:13.07 |
brlcad |
it's like compilation errors/warnings, should
take care of them in order |
01:13.11 |
brlcad |
as many cascade |
01:13.28 |
poolio |
would you like --show-reachable or
no? |
01:15.04 |
brlcad |
doesn't matter yet |
01:15.08 |
brlcad |
default output is fine |
01:15.13 |
poolio |
k |
01:15.21 |
poolio |
so you dont even want --leak-check? |
01:16.05 |
brlcad |
leave them both in |
01:16.14 |
brlcad |
shouldn't matter, there's plenty to work with
:) |
01:16.28 |
brlcad |
each one of those could take an hour or 30
seconds |
01:16.34 |
brlcad |
or longer |
01:16.41 |
poolio |
eeeek. |
01:17.12 |
poolio |
brlcad: http://poolio.org/~poolio/valgrind_output |
01:17.14 |
brlcad |
the ptbl one is surprising -- it should leave
a few bytes, but certainly not accummulate like that |
01:17.34 |
poolio |
well remember how many times I'm calling
everything...a whole hell of a lot |
01:18.08 |
poolio |
note: that's the output from a run with pop
size of 20, 50 generations, and 10x10 rays |
01:18.47 |
brlcad |
I know, but when I said it was a "known
issue", it's only known that there is a final allocation that is
not freed until exit |
01:18.55 |
poolio |
ah I see |
01:19.00 |
brlcad |
even subsequent calls to init should clear out
the previous |
01:19.10 |
brlcad |
so either there is a call missing or a leak in
the library |
01:19.24 |
brlcad |
i'd still start from the top of that list,
though |
01:20.09 |
brlcad |
are you up to date and commited? |
01:20.36 |
poolio |
yep. |
01:21.58 |
louipc |
in spkr.s tor 16 16 16 1 0 0 12 1 |
01:22.10 |
louipc |
that causes mged to quit with "Illegal
Instruction" |
01:22.56 |
brlcad |
louipc: that's working fine for me
here |
01:23.18 |
brlcad |
what version are you on? |
01:23.26 |
brlcad |
cvs head? |
01:23.38 |
louipc |
yea |
01:23.52 |
brlcad |
stack trace? |
01:24.13 |
brlcad |
gdb --args mged -c test.g in spkr.s tor 16 16
16 1 0 0 12 1 |
01:24.18 |
brlcad |
run |
01:24.19 |
brlcad |
bt |
01:24.26 |
brlcad |
pastebin :) |
01:25.49 |
louipc |
ahh I was trying to figure that out |
01:32.31 |
louipc |
hopefully that's useful :) http://pastebin.archlinux.org/11583 |
01:33.29 |
CIA-29 |
BRL-CAD: 03brlcad *
10brlcad/configure.ac: |
01:33.29 |
CIA-29 |
BRL-CAD: remove the 'automatic flags'
configure option (royal pita to keep track of |
01:33.29 |
CIA-29 |
BRL-CAD: cleanly in the configure logic for
trivial gain) for now; rename the aquatk |
01:33.29 |
CIA-29 |
BRL-CAD: configure option to be consistent
with the others and make it actually pass that |
01:33.29 |
CIA-29 |
BRL-CAD: on to tk's configure; and add a
proper JavaVM framework check, using it instead |
01:33.31 |
CIA-29 |
BRL-CAD: of a platform test. |
01:36.50 |
brlcad |
hm, interesting trace .. it's trying to draw
the tor so it did make it |
01:37.43 |
poolio |
brlcad: do you have time now to go over the
valgrind output or would you rather do it later? (I have some other
things to do that are flexible but I'd rather not just sit around
:)) |
01:37.47 |
brlcad |
poolio: if you add this to main, is there
still the qsort in the output: |
01:37.47 |
brlcad |
<PROTECTED> |
01:37.53 |
poolio |
ah k, one sec. |
01:38.43 |
brlcad |
it's really odd that it's whining about
uninitialized values -- there's only three params |
01:38.49 |
brlcad |
pop and the function |
01:39.03 |
brlcad |
so I'm thinking it's pop |
01:39.25 |
brlcad |
and the conditional is the fact that
pop_init() could conceivably be overridden at run-time |
01:39.39 |
brlcad |
that would then explain printf as
well |
01:40.46 |
poolio |
brlcad: err nope. |
01:40.56 |
brlcad |
seriously? damn. |
01:41.10 |
poolio |
unless I'm executin the wrong binary |
01:41.28 |
brlcad |
how are you running it? |
01:41.36 |
poolio |
valgrind .libs/beset |
01:41.52 |
brlcad |
eepish |
01:42.04 |
brlcad |
ldd .libs/beset |
01:42.23 |
poolio |
you desire that output |
01:42.23 |
poolio |
? |
01:42.38 |
brlcad |
you have to wrap (so either adding valgrind to
the wrapper script or setting ld_lib manually |
01:42.50 |
brlcad |
I suspect it says /usr/brlcad/... |
01:42.57 |
poolio |
nope |
01:43.05 |
poolio |
I have them in /usr/lib |
01:43.10 |
poolio |
--prefix=/usr |
01:43.11 |
poolio |
I'm lazy like that. |
01:43.14 |
brlcad |
okay, whatever your prefix is |
01:43.29 |
brlcad |
you know that will clobber some of your system
libs on most linux systems |
01:43.40 |
louipc |
:D |
01:43.42 |
poolio |
Probalby, but I'm reinstalling the distro when
I'm done working |
01:43.49 |
poolio |
So it doesn't really matter much |
01:43.57 |
poolio |
good to knwo though :) |
01:44.18 |
brlcad |
the most common is usually librt |
01:44.43 |
brlcad |
which is a deprecated "real time
compatibility" library that they've been planning to ditch for many
years |
01:44.56 |
brlcad |
our librt predates them by about a decade too,
but that's just the way things are |
01:45.31 |
brlcad |
similarly libbu and libbn conflict with some
packages like curl also has a (private yet installed) "big number"
library named the same |
01:45.53 |
brlcad |
er, not curl .. maybe openssl, one of those
guys |
01:46.03 |
poolio |
fight it out for rights to library
names |
01:46.03 |
brlcad |
and a handful of others |
01:46.29 |
brlcad |
oh, we've stood our ground to date, though it
does make integration with package management systems
complicated |
01:47.41 |
brlcad |
plus we really can't for the core libraries
for many many reasons (and that includes the most often
conflicting, libbu, libbn, librt) |
01:49.32 |
brlcad |
louipc: did you compile with
-ffast-math? |
01:49.50 |
brlcad |
I see that it's optimized, I'm wondering if
it's bad math juju |
01:52.38 |
poolio |
brlcad: pardon my lack of bash scripting, but
what exactly does ${1+"$@"} do? an array of |
01:52.49 |
poolio |
$@ is arguments? |
01:57.27 |
poolio |
ah I see |
01:58.37 |
brlcad |
it's just a quirky way of expanding the
arguments |
01:58.49 |
brlcad |
"$@" expands to the command line
arguments |
02:00.50 |
brlcad |
it makes more since if it includes the
: |
02:01.02 |
brlcad |
i.e. ${1:+"$@"} |
02:01.08 |
poolio |
brlcad: no change |
02:01.25 |
brlcad |
which means .. "if it has $1 set, then
substitute $@" |
02:01.50 |
poolio |
yeah, I got the clue when I changed it and it
sad bad substitution |
02:01.53 |
poolio |
s/sad/said |
02:02.03 |
brlcad |
$@ is basically $1 $2 $3 $4 ... |
02:02.33 |
brlcad |
so it's kinda fruity to do it that way, but it
probably matters for some old system if someone did it that
way |
02:02.37 |
poolio |
brlcad: http://poolio.org/~poolio/val |
02:03.08 |
brlcad |
ooh, i don't think i noticed cmd_ind
before |
02:03.25 |
poolio |
cmp_ind? |
02:03.35 |
poolio |
it was there. same output :) |
02:04.27 |
brlcad |
yeah, I see it now |
02:05.04 |
brlcad |
so it's basically saying either the pop
element is potentially uninitialized for some reason, or fitness
specificially is |
02:05.16 |
brlcad |
that's.. |
02:05.19 |
brlcad |
odd |
02:06.15 |
brlcad |
er, not pop.. pop.parent |
02:06.21 |
poolio |
well it's potentially true if pop_spawn()
wasn't called |
02:06.37 |
poolio |
pop.parent is alloc'ed but none of the
variables are intiialized until pop_spawn() is called |
02:17.16 |
poolio |
brlcad: you might want to try running valgrind
locally....I may have just royally fscked something on my
end |
02:19.56 |
brlcad |
i was about to actually, to see if I can
reproduce it |
02:20.02 |
brlcad |
what's your inputs look like? |
02:20.09 |
poolio |
./beset source.g test.r |
02:20.30 |
poolio |
source.g is the database that contains
test.r |
02:20.41 |
poolio |
test.r is just a region with two spheres
unioned together |
02:20.54 |
brlcad |
louipc: looking at that function, the only
thing I can see *might* be a problem is if you had non-ieee
floating point -- do you have your config.log from the compile on
hand somewhere? |
02:21.18 |
poolio |
Any region should do |
02:21.18 |
poolio |
in any database |
02:21.18 |
brlcad |
okay |
02:21.18 |
brlcad |
so no population sizes or iteration
counts |
02:21.52 |
poolio |
it defaults to 50 pop size, i think 20
generations, and a resolution of 10x10, (doesnt kill/keep any
lower/upper) |
02:22.00 |
poolio |
hmm |
02:22.10 |
poolio |
lemme update options documentation, forget the
-u -l |
02:27.28 |
CIA-29 |
BRL-CAD: 03poolio *
10brlcad/src/gtools/beset/beset.c: documented -u and -l
options |
02:45.29 |
poolio |
brlcad: no luck? |
02:45.49 |
poolio |
ah alright :) |
02:46.27 |
brlcad |
(whilst shaiking fist at louipc..) |
02:48.05 |
brlcad |
he either uncovered something rather
surprising that hasn't come up in at least a decade, or something
entirely different is going on with that crash |
02:48.58 |
brlcad |
either way, I have to rebuild now cause of
core changes |
02:58.21 |
*** join/#brlcad SWPadnos_
(n=Me@dsl245.esjtvtli.sover.net) |
03:44.41 |
poolio |
brlcad: sorry to keep bugging you, I'm just
kind of clueless as to what to do from here... it seems like there
is some sort of overflow somewhere but it doesn't make much sense
and I feel like it'd be segfaulting if that was the case |
03:45.17 |
louipc |
brlcad: I rebuilt with debugging symbols and
made a more detailed trace http://pastebin.archlinux.org/11584 |
03:57.02 |
*** join/#brlcad louipc
(n=louipc@bas8-toronto63-1088754591.dsl.bell.ca) |
04:30.22 |
poolio |
tis not possible! brlcad left :o |
06:15.10 |
*** join/#brlcad tofu
(n=sean@bz.bzflag.bz) |
07:16.06 |
*** join/#brlcad Laniakea
(n=clock@zux221-122-143.adsl.green.ch) |
09:14.45 |
*** join/#brlcad Laniakea
(n=clock@zux221-122-143.adsl.green.ch) |
12:25.32 |
*** join/#brlcad thing0
(n=ric@203-59-92-250.dyn.iinet.net.au) |
13:10.50 |
``Erik |
heh |
13:10.55 |
``Erik |
all your connection are belong to me |
13:26.13 |
*** join/#brlcad poolio
(n=poolio@c-69-251-3-107.hsd1.md.comcast.net) |
15:13.05 |
*** join/#brlcad elite01
(n=elite01@dslb-088-070-025-240.pools.arcor-ip.net) |
16:10.43 |
poolio |
brlcad: anything? |
17:14.29 |
*** join/#brlcad yukonbob
(n=yukonbob@whthyt224-180.northwestel.net) |
17:31.41 |
``Erik |
BRL-CAD runs on solaris 5.8 with the gnu build
chain, just ran mged and did a few traces of sphflake |
17:41.09 |
*** join/#brlcad PrezKennedy
(i=Matt@74.86.45.130) |
17:42.39 |
PrezKennedy |
shazaam! |
17:44.46 |
poolio |
``Erik: you know where brlcad has disappeared
to? |
17:45.30 |
PrezKennedy |
he is among us! a commoner :-O |
17:47.47 |
``Erik |
ummmm |
17:49.29 |
``Erik |
lets see, on saturday he's flying, which means
today he's holed up and out of site tying to push 7.10.2 out the
door |
17:49.37 |
``Erik |
out of sight |
17:49.46 |
poolio |
crap. |
17:49.57 |
``Erik |
anything I can do for ya? |
17:50.26 |
poolio |
``Erik: if you have the time, I've got some
odd leaks...The issue is that I'm trying to do larger test
runs...and it leaks so much that it locks my system up (uses up all
memory and swap) |
17:50.29 |
``Erik |
<-- not as versed in the finer guts of the
package, but likes to pretend he's not a complete retard once in a
while |
17:50.47 |
poolio |
``Erik: eh, you know much more than I do, any
help would be appreciated, I'm pretty stuck |
17:50.49 |
``Erik |
is valgrind reporting it as reachable
memory? |
17:50.59 |
poolio |
``Erik: valgrind output is here: http://poolio.org/files/val |
17:51.09 |
poolio |
``Erik: some of it, a lot of it is
lost |
17:52.13 |
``Erik |
10-13m lost, 5 reachable |
17:52.15 |
``Erik |
um |
17:52.32 |
``Erik |
what if you do what it says on the last line
and run i with --leak-check=full ? :D |
17:52.40 |
poolio |
yeah sure |
17:53.32 |
poolio |
maybe? not sure. changes from run to run so
it's probably pid |
17:53.53 |
``Erik |
<-- generally only touches linux when
porting, so is not that familiar with valgrind |
17:54.00 |
``Erik |
as my rant yesterday may've indicated
:) |
17:54.11 |
poolio |
:) if you want you could use whatever you use
on it locally |
17:54.45 |
poolio |
it's in cvs src/gtools/beset |
17:55.05 |
``Erik |
<-- has no source data or clue of how to
use it :) |
17:55.15 |
``Erik |
also; when I try compiling it with my happy
flags, it breaks like a mofo |
17:55.49 |
poolio |
source data is simple |
17:55.53 |
poolio |
a database, with a region in it |
17:55.55 |
poolio |
that's all it needs |
17:56.23 |
poolio |
``Erik: oh yeah. I can probably fix that. What
flags are you using again? (relevant pedantic/warnings
etc..) |
17:56.27 |
``Erik |
so I could make a sphere or metaball and just
use that? your code voxelizes and then tries to regenerate the
initail data from the voxelized set? |
17:58.12 |
``Erik |
-W -Wall -Werror -ansi -pedantic -pipe
-fno-strict-aliasing -fno-common -fexceptions -O3
-march=opteron |
17:58.15 |
``Erik |
or so |
17:58.40 |
poolio |
Jah :) Not exactly voxelized but close enough.
It stores the rays |
17:59.17 |
``Erik |
well, that's one mechanism for
voxelizing |
17:59.49 |
``Erik |
no one said it has to be a regular grid...
indeed, many have moved to irregular tetrahedral grids |
17:59.59 |
poolio |
ah alright, then yes. |
18:00.34 |
poolio |
``Erik: oh, the issue is my use of // ...
that's not in C89 I think |
18:00.53 |
``Erik |
no, // was introduced in c99 |
18:01.02 |
``Erik |
and we're still c89 ansi for the most
part |
18:01.27 |
``Erik |
I did a sed -i.bak 's,//.*,,' *.[ch] the other
day and still got build errors, iirc |
18:01.28 |
poolio |
Alright, brlcad said it was fine though, and
I'm too lazy to change thar gith now. Most of the // comments are
ones that are temporary while it's in active development. |
18:01.36 |
``Erik |
using gcc42 |
18:01.59 |
poolio |
well I might have some weird comments that are
in odd forms |
18:02.18 |
*** join/#brlcad dtidrow
(n=dtidrow@host131.objectsciences.com) |
18:02.30 |
``Erik |
initially, I did something like s,//\(.*\),/*
\1 */, |
18:02.42 |
``Erik |
but was foiled by things that looked like //
blah /* something */ |
18:02.55 |
poolio |
yeah |
18:04.04 |
poolio |
``Erik: if you kill ansi and pedantic because
of comments, and just use -W -Wall it works fine (there's some
unused variable warnings that don't make sense to change) |
18:04.08 |
poolio |
well unused parameter |
18:07.58 |
``Erik |
I can do it without the gooby flags, I mostly
said that to piss ya off ;) |
18:08.27 |
poolio |
well, it's a good point. It will be cleaned up
at some time. But it'd be great if you killed off your handy dandy
flags and just let it build for now. |
18:08.37 |
``Erik |
running an update now, but it'ts going
vvvveeeerrrrryyyy slow. for some reason, my mac doesn't like
tlaking nfs to my nfs server so much the last couple days |
18:08.54 |
poolio |
sorry |
18:09.37 |
``Erik |
and the boy changed configure.ac, so I'll have
to sit around waiting for autoregen after the update
*sigh* |
18:09.46 |
poolio |
oh geez |
18:09.51 |
poolio |
cya in a couple days ;) |
18:10.53 |
``Erik |
won't take QUITE that long |
18:10.57 |
``Erik |
but won't exactly be instance :/ |
18:11.26 |
``Erik |
instant |
18:11.33 |
``Erik |
too much wow :( I suck |
18:11.44 |
poolio |
You play WoW? |
18:12.25 |
``Erik |
yes :( |
18:12.29 |
``Erik |
gf made me, now I'm hooked |
18:12.43 |
``Erik |
ffs, 3 instances of 'scrub' running on the
same fs at the same time, wtf |
18:13.01 |
poolio |
Wait wait. Your girlfriend made you play WoW?
That's awful. Quit while you still can |
18:13.53 |
``Erik |
hah |
18:14.07 |
``Erik |
she was pissed at me yesterday cuz I kept
playing wow |
18:14.23 |
``Erik |
and my lower level char is higher than her
high level one |
18:14.52 |
*** join/#brlcad Laniakea
(i=clock@77-56-106-16.dclient.hispeed.ch) |
18:15.45 |
poolio |
Quit. |
18:17.01 |
PrezKennedy |
wow sucks... |
18:17.21 |
PrezKennedy |
just had to get that out there ;-) |
18:17.22 |
``Erik |
you suck |
18:17.31 |
``Erik |
I'd say your mom sucks, but she's cool :/ so I
can't do that |
18:17.47 |
``Erik |
:D |
18:17.58 |
PrezKennedy |
haha |
18:18.46 |
``Erik |
(also; ben, my big tool for finding and fixing
major leaks is "don't put them in there in thte first place" :D
) |
18:18.54 |
``Erik |
debugging is a pain, so don't put the bugs
in |
18:19.19 |
poolio |
Thanks ``Erik, maybe some day I'll be a better
coder. |
18:19.44 |
``Erik |
what's a good object to get your freaky
behavior? is a sphere sufficient? |
18:19.53 |
poolio |
yeah |
18:20.00 |
poolio |
it's not caused by the input data |
18:20.10 |
``Erik |
<-- has been coding for 24 years, is still
trying to be a better coder |
18:21.24 |
Laniakea |
``Erik: how old are you? |
18:22.41 |
poolio |
Run it like ./beset db.g region.r |
18:23.11 |
``Erik |
ancient :( |
18:23.43 |
``Erik |
not as old as john, though |
18:23.49 |
``Erik |
<-- about to turn 31 |
18:29.06 |
``Erik |
hum, ok |
18:29.12 |
``Erik |
it ran in .25 seconds O.o |
18:29.21 |
poolio |
``Erik: oh yeah, so if you want it to run
longer |
18:29.27 |
poolio |
specificy some options to do so |
18:29.28 |
poolio |
so |
18:29.38 |
poolio |
./beset -p 300 -g 100 -r 32 db.g
region.r |
18:29.45 |
``Erik |
heh |
18:29.47 |
poolio |
./beset for documentation |
18:29.49 |
``Erik |
I did -p 1000 -g 1000 |
18:29.53 |
poolio |
errr |
18:30.03 |
poolio |
i mean, I have a slow laptop, so you might be
able to take that |
18:30.03 |
``Erik |
tat slows it down enough to watch it
grow |
18:30.12 |
``Erik |
quad opteron 2.0ghz with 8g ram |
18:30.20 |
``Erik |
I figured I wanted a slower machine to do it
on |
18:30.21 |
``Erik |
:D |
18:30.23 |
poolio |
yeah fair enough, I'm just not sure how to
exit gracefully and have valgrind catch it? |
18:30.31 |
``Erik |
no valgrind, not linux |
18:30.31 |
poolio |
...that's slow? rawr. |
18:30.41 |
``Erik |
the linux boxes are 8 core |
18:30.43 |
``Erik |
is this threaded? |
18:30.50 |
``Erik |
doesn't look like it |
18:30.51 |
poolio |
it was, I disabled the threading for
testing |
18:31.10 |
poolio |
the codes in there, just commented out for now
while I try to fix these leaks |
18:31.47 |
``Erik |
ok, -p 1000 -g 10 takes 3sec, that should be
sufficient |
18:32.00 |
poolio |
k :) |
18:32.24 |
poolio |
3 seconds? geez man. |
18:32.27 |
poolio |
well I'm not running optimized |
18:33.32 |
``Erik |
hum |
18:33.36 |
``Erik |
beset in free(): warning: junk pointer, too
high to make sense |
18:33.48 |
poolio |
where in beset? |
18:34.15 |
``Erik |
heh, doesn't say, gonna add some stuf fin...
happens at the very beginning |
18:34.39 |
poolio |
hmm alright |
18:34.46 |
poolio |
(no frees are directly called by
beset.c) |
18:35.07 |
``Erik |
no bound overwrites |
18:35.26 |
poolio |
that's good. does that mean there can't be any
stack overflow? |
18:35.32 |
poolio |
well stack corruption |
18:35.58 |
``Erik |
I'd assume |
18:36.35 |
``Erik |
boehm seems to crash |
18:36.44 |
``Erik |
probably from that pointer error |
18:37.03 |
poolio |
the free() one? |
18:37.22 |
``Erik |
yeah |
18:37.44 |
poolio |
can you specify more t han free() in beset?
there aren't any direct free()s called in beset.c is there a
backtrace for it or something? |
18:38.04 |
``Erik |
no backtrace, unfortunately |
18:38.26 |
poolio |
so the only thing youc an say is there's some
bogus pointer being free()'d somewhere near the beginning of the
program? |
18:39.09 |
poolio |
Could I narrow that down by adding some printf
debugging output at certain intervals in between
routines? |
18:39.31 |
``Erik |
I can add those, just sit tight a few, I'm
getting some environments rigged up |
18:39.32 |
``Erik |
:) |
18:39.37 |
poolio |
Alright thanks |
18:39.51 |
poolio |
Oh wait...here's a big idea. Do I need to free
the partition and segments list passed to the a_hit
routine? |
18:42.34 |
``Erik |
the junk pointer stuff is at _init() time
:/ |
18:43.24 |
``Erik |
uhmmmm, hrm, I'm not sure :) |
18:44.09 |
``Erik |
I don't THINK so, but I'm not sure |
18:44.11 |
poolio |
So I really have no control over the junk
pointer you're talking about right? |
18:44.56 |
``Erik |
right |
18:45.11 |
poolio |
It doesn't look like I need to clean up the
partitions/segments. g_qa doesn't |
18:45.26 |
poolio |
That's what I based the raytracing section of
beset off of |
18:46.14 |
``Erik |
heh |
19:11.55 |
poolio |
hmm |
19:12.11 |
poolio |
I have some ideas for optimizations, but none
for fixing the leaky software :P |
19:12.44 |
``Erik |
how irritating, valgrind doesn't lilke
amd64 |
19:12.50 |
``Erik |
it seems it's JUST for i386 linux |
19:13.33 |
``Erik |
and opennurbs sucks big hairy goat balls and
has my mac build all plugged up |
19:13.44 |
poolio |
sorry |
19:16.52 |
``Erik |
what if; |
19:17.15 |
``Erik |
add externs in beset.c, then at the beginning
of the loop in beset.c, null them out... and see if valgrind hleps
there? |
19:17.20 |
``Erik |
or did you try that already? |
19:17.41 |
poolio |
well, I null them at the beginning of
pop_gop |
19:17.46 |
poolio |
so they are nulled each iteration |
19:17.53 |
poolio |
(before they are used) |
19:19.49 |
``Erik |
hrmmmm |
19:24.04 |
poolio |
``Erik: I just updated CVS if you want to try
it |
19:24.13 |
poolio |
also now you fun flags will work (except
-Werror) |
19:24.28 |
CIA-29 |
BRL-CAD: 03poolio * 10brlcad/src/gtools/beset/
(6 files): now conforms to C89 |
19:52.36 |
``Erik |
hrmmmm |
19:52.50 |
``Erik |
it doesn't look like the allocs that are
leaking are in src/gtools/beset |
19:58.44 |
``Erik |
hummmmm |
19:58.53 |
``Erik |
iiiinteresting, |
19:59.07 |
``Erik |
are any of these numbers magic? 36 4.5
2.25 |
20:07.52 |
poolio |
``Erik: errr, not as far as I know |
20:08.55 |
poolio |
``Erik: I remember brlcad saying something
about bu_ptbl_init...maybe there? |
20:09.26 |
``Erik |
hrm |
20:09.40 |
``Erik |
there're 36 retained records for -p 1 -g
1 |
20:10.09 |
``Erik |
when I bump it to -p 10 -g 1, it's 2.25x, and
-p 1 -g 10 is 4.5x |
20:10.25 |
poolio |
weird |
20:11.05 |
``Erik |
(and obviously, 2.25*2=4.5 |
20:11.06 |
``Erik |
) |
20:11.33 |
``Erik |
(also; I wouldn't rule out g_qa leaking like a
seive) |
20:11.39 |
poolio |
heh alright] |
20:12.22 |
poolio |
Something to note, -p 1 - g 1 doesn't do
anything in terms of the GA. It spawns a population, saves that to
a database, and exits. |
20:12.40 |
poolio |
well -p 1 means it'll just spawn one
individual and save it to a database and exit |
20:12.41 |
``Erik |
ok, right, because g-1 |
20:12.50 |
``Erik |
so -g 10 does 0-8 |
20:12.57 |
``Erik |
which seems... odd |
20:12.58 |
``Erik |
:) |
20:13.00 |
poolio |
well |
20:13.04 |
poolio |
it does 0-9 |
20:13.06 |
poolio |
(geenrates the population) |
20:13.11 |
poolio |
but we dont evaluate the fitness for the last
generation |
20:13.19 |
``Erik |
okie |
20:13.22 |
``Erik |
well |
20:13.31 |
``Erik |
hm |
20:13.36 |
poolio |
It has to do with the way the loop is
worked |
20:13.45 |
``Erik |
if -p 10 -g 1 shows growth |
20:13.59 |
``Erik |
I'd assume that might mean your leak might
possibly be in your population generation |
20:14.11 |
``Erik |
maybe |
20:14.26 |
poolio |
spawn_first_generation();
for(each_generation){evaluate fitness of previous and spawn new
generation} |
20:14.46 |
poolio |
Seems so, let me check. |
20:15.16 |
poolio |
ah d'oh. there is leakage there |
20:15.19 |
poolio |
let me fix that up |
20:15.38 |
*** join/#brlcad Apathy
(i=Matt@74.86.45.130) |
20:15.47 |
poolio |
I don't think mk_sph would (I think cleanup of
the db ointer would do that) |
20:16.01 |
poolio |
mk_addmember might |
20:16.11 |
poolio |
well that'd be part of the wm_hd list cleanup
I'm about to write |
20:17.47 |
*** join/#brlcad IriX64
(n=mariodot@bas2-sudbury98-1096601569.dsl.bell.ca) |
20:18.02 |
*** join/#brlcad Laniakea
(i=clock@77-56-106-16.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
20:18.02 |
*** join/#brlcad CIA-29
(n=CIA@208.69.182.149) |
20:18.18 |
IriX64 |
testing found this ---> http://rafb.net/p/GJBQ0l79.html |
20:18.58 |
``Erik |
yeah, it's in src/other so it's someone elses
problem... there're a fistful of those in our code, too, I
think |
20:19.24 |
IriX64 |
thankyou |
20:19.35 |
IriX64 |
i'll fix my copy :) |
20:20.02 |
poolio |
``Erik: none of the code in proc_db cleans up
the wm_hd lists |
20:20.22 |
poolio |
I don't think it needs to be actually... but
I'll try anyway |
20:20.40 |
IriX64 |
invoke mr_clean() :) |
20:21.55 |
IriX64 |
ahem, i return to my own trials and
tribulations, sorry poolio :) |
20:22.04 |
poolio |
:( |
20:23.14 |
``Erik |
poolio, it's highly possible that a lot of
this stuff expects only one run and does not clean up, assuming the
OS will clean up at exit... :/ you're presenting a unique challenge
to the framework :) |
20:23.42 |
*** join/#brlcad Laniakea
(i=clock@77-56-106-16.dclient.hispeed.ch) [NETSPLIT
VICTIM] |
20:23.42 |
*** join/#brlcad CIA-29
(n=CIA@208.69.182.149) |
20:24.54 |
poolio |
``Erik: argh. Also: there's no de-init needed
in pop_spawn() with the wm_hd...all of it should clean itself up at
the end of the routine |
20:25.17 |
``Erik |
once I have a re-done build |
20:25.23 |
``Erik |
I'm going to commit grave fugliness |
20:25.29 |
poolio |
ah. which is? |
20:25.40 |
``Erik |
and tap it with a debugger to see if I can get
a stack trace on one of those leak points |
20:25.53 |
poolio |
alright, you're over my head. thanks a ton for
the help |
20:26.00 |
``Erik |
heh |
20:26.19 |
``Erik |
I have the addresses of the un-freed
things |
20:26.38 |
``Erik |
I'm going to put something in bu_malloc() that
searches for some of those addresses |
20:26.53 |
``Erik |
"if the pointer happens to be 0x080c2351,
break to debugger" |
20:26.54 |
``Erik |
:) |
20:26.57 |
``Erik |
hopefully it works |
20:26.58 |
poolio |
wow |
20:27.01 |
poolio |
that is really friggin fugly. |
20:27.11 |
``Erik |
<-- king of ugly |
20:27.22 |
``Erik |
but sometimes it works, then I look godlike
:D |
20:27.34 |
poolio |
hehe |
20:28.03 |
poolio |
so you don't think the leaks have to do with
anything I could fix in beset? |
20:28.08 |
``Erik |
well |
20:28.12 |
``Erik |
they're not actually leaks |
20:28.28 |
``Erik |
just not freed when they should be... there's
still a path to them |
20:28.44 |
poolio |
wait |
20:29.06 |
poolio |
so most of the memory leaks are reachable
things that were allocated in the stack and weren't properly freed
when their respective routines exited? |
20:30.07 |
``Erik |
no |
20:30.30 |
``Erik |
only active frames of the stack are
considered |
20:30.48 |
``Erik |
otherwise, valgrind SHOULD see it as an omfg
leak |
20:30.54 |
poolio |
heh alright |
20:37.47 |
IriX64 |
mc |
20:43.02 |
*** join/#brlcad iraytrace
(n=iraytrac@cocoa.sci.utah.edu) |
20:51.26 |
``Erik |
iiiinteresting |
20:51.46 |
``Erik |
oi, lee |
20:53.03 |
iraytrace |
Evenin |
20:53.13 |
``Erik |
the first one is in rt_gettree() |
20:55.52 |
poolio |
maybe lee can fix all the bugs. :) |
20:56.12 |
poolio |
is this big boss man lee? |
20:56.36 |
``Erik |
no, this is whipping boy expatiate lee
:) |
20:57.08 |
iraytrace |
He's got *that* right. |
20:57.32 |
poolio |
ouch. |
20:57.34 |
iraytrace |
poolio: It's great too see what you've been
doing |
20:57.39 |
``Erik |
so your report was sat on past the
deadline? |
20:57.50 |
iraytrace |
:-( |
20:58.00 |
iraytrace |
There's more to it than just that |
20:58.24 |
poolio |
iraytrace: thanks. It's been quite slow and
frustrating though. I expected to be so much further so much
faster. |
20:58.53 |
``Erik |
poolio, this is what I'm looking at now, as
the 'first possible culprit': http://pastebin.bzflag.bz/d43fc0cc6 |
20:59.13 |
poolio |
valgrind picked that up |
20:59.26 |
poolio |
let me find the valgrind snippet |
20:59.31 |
poolio |
(not in that much detail of course) |
21:02.15 |
poolio |
``Erik: http://rafb.net/p/McsUKV59.html
<-- valgrind gets it too |
21:04.07 |
``Erik |
hum |
21:05.03 |
poolio |
hmm |
21:05.57 |
poolio |
so another possibility, I remember brlcad
talking about offsets in the internal objects. I currently write
the same internal object from one database into the next database
without modifying the internal object in any way (just creating a
new directory in the new database). Is there something i need to do
to the rt_db_internal structure before I write it out to the new
database? |
21:06.20 |
``Erik |
<-- has no idea |
21:07.01 |
poolio |
hmm. I think it's not that. I feel like that
would manifest itself as collisions between to rt_db_internal
structs with the same offset and blow up. But it appears that the
code works fine aside from the leaks. |
21:08.01 |
poolio |
(and the databases aren't corrupt or
anything) |
21:08.29 |
poolio |
Also, that whole situation of copying internal
objects doesn't occur with a generation size of one |
21:16.13 |
poolio |
Oh. That's a pain. |
21:17.18 |
poolio |
It looks like it is rt_gettree(). It does
happen with g=1 because I raytrace the region that is passed as an
argument and rt_gettree() is called on that |
21:20.58 |
``Erik |
based on how it's used elsewhere |
21:21.21 |
``Erik |
hum, I was looking at this line before,
heh |
21:21.44 |
``Erik |
wait, you don't prep, do you? |
21:21.53 |
poolio |
rt_prep()? I do |
21:22.01 |
poolio |
ah does that call gettree? |
21:22.35 |
``Erik |
no, that's what cleans up gettree |
21:22.43 |
poolio |
oh |
21:23.50 |
poolio |
look at fit_rt() in fitness: rtip =
rt_new_rti(db); rt_gettree(rtip); rt_prep(rtip); ...shoot
rays... |
21:24.00 |
poolio |
and finally rt_clean(rtip) |
21:25.01 |
``Erik |
not rt_free_rti() ? |
21:25.19 |
poolio |
no |
21:25.31 |
poolio |
I previously had rt_free_rti() but siwtched to
rt_clean(). Do I need to do both? |
21:25.51 |
``Erik |
rt_free_rti() calls rt_clean() and does some
other stuff |
21:26.01 |
poolio |
hmm ok |
21:26.33 |
poolio |
rawr. |
21:26.42 |
poolio |
Why did I change it to
rt_clean()????????? |
21:27.51 |
poolio |
err still get the rt_gettree leak |
21:31.23 |
``Erik |
hum, actually, I think we found different
things O.o |
21:32.36 |
poolio |
hmm? |
21:32.52 |
poolio |
I have a feeling I'm not properly
comprehending what is allocated and unallocated in the
rtip |
21:33.10 |
``Erik |
heh, same here |
21:33.50 |
poolio |
<PROTECTED> |
21:34.09 |
poolio |
is that different than
rt_uniresource? |
21:40.45 |
poolio |
``Erik: argh I have to go, but I'll be around
later. If you come across anything just write it in here or send me
an e-mail and I'll see it in a couple hours. Thanks again for all
the help |
21:42.15 |
``Erik |
np |
21:47.55 |
``Erik |
http://egv8.game.googlepages.com/home |
22:00.29 |
iraytrace |
The rt_uniresource is a single resource
allocated by the library |
22:00.43 |
iraytrace |
For multiple, the application has to
alloc/dealloc |
23:34.53 |
*** join/#brlcad b0ef
(n=b0ef@062016141081.customer.alfanett.no) |
23:46.21 |
*** join/#brlcad iraytrace
(n=iraytrac@cocoa.sci.utah.edu) |