IRC log for #brlcad on 20120206

06:03.48*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
07:51.25*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:07.09*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:13.54*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
08:17.00*** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:29.44*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
08:42.23*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
09:13.46*** join/#brlcad pawleeq (~pawleeq@212-96-188-229.cust.selfnet.cz)
09:34.59*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
09:58.12*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:35.46*** join/#brlcad packrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net)
11:35.46*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
11:35.46*** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net)
11:35.46*** join/#brlcad kanzure (~kanzure@131.252.130.248)
11:35.46*** join/#brlcad n_reed_ (~molto_cre@BZ.BZFLAG.BZ)
11:35.46*** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net)
11:35.46*** join/#brlcad DarkCalf (DC@173.231.40.98)
11:35.46*** join/#brlcad louipc (~louipc@archlinux/fellow/louipc)
11:35.46*** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ)
11:35.46*** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ)
11:35.46*** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com)
11:35.46*** join/#brlcad cvds_ (~leila@e255180.upc-e.chello.nl)
11:35.47*** join/#brlcad Maloeran (~maloeran@mail.catchgamer.no)
11:35.47*** join/#brlcad ``Erik (~erik@BZ.BZFLAG.BZ)
11:35.47*** join/#brlcad piksi (piksi@pi-xi.net)
11:35.47*** join/#brlcad CIA-48 (~CIA@cia.atheme.org)
11:35.47*** join/#brlcad ChanServ (ChanServ@services.)
11:35.47*** mode/#brlcad [+o ChanServ] by niven.freenode.net
12:24.42*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
13:09.00``Erikhuh, something kicked up on bz at 3:15 this morning, added ~30% cpu usage
14:38.19brlcadprolly someone browsing porn through a proxy
14:50.13``Eriklooks like google decided to do a big sweep again and encounting some errors, maybe? (6.5 hrs and counting, .3 cpu, all seems to be in httpd?)
15:28.21*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
15:34.44brlcadlooks like a couple bots are walking content at the moment
15:34.57brlcadhttp://www.globalspec.com/Ocelli being one, googlebot another
16:41.43CIA-48BRL-CAD: 03starseeker * r49241 10/brlcad/trunk/ (2 files in 2 dirs): Need to take some extra care with the iwidgets manpages since CMake is prefixing them.
16:50.44CIA-48BRL-CAD: 03starseeker * r49242 10/brlcad/trunk/src/other/CMakeLists.txt:
16:50.45CIA-48BRL-CAD: INSTALL.new on CMake is different because we're not running the THIRD_PARTY
16:50.45CIA-48BRL-CAD: macro for SCL on Windows. Try a different approach to disabling SCL with MSVC
16:50.45CIA-48BRL-CAD: that should let the THIRD_PARTY macro run. This will be moot once we get SCL
16:50.45CIA-48BRL-CAD: working with MSVC, and can go away then.
17:28.46*** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
17:33.57CIA-48BRL-CAD: 03brlcad * r49243 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/str.c):
17:33.57CIA-48BRL-CAD: header says null is a perfectly valid parameter to bu_strcmp() so there's no
17:33.57CIA-48BRL-CAD: need to print it. so get rid of the label parameter since it's otherwise
17:33.57CIA-48BRL-CAD: unused. that means the function can take on the macro name and the macro can go
17:33.57CIA-48BRL-CAD: away. round out the offering with implementations for strncmp() and
17:33.58CIA-48BRL-CAD: strncasecmp() too.
17:37.10*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
18:03.28CIA-48BRL-CAD: 03brlcad * r49244 10/brlcad/trunk/include/bu.h: eep, update the macros calls to bu_strcmpm() to bu_strcmp()
18:04.14CIA-48BRL-CAD: 03brlcad * r49245 10/brlcad/trunk/include/bu.h: save the file, then commit
18:10.56CIA-48BRL-CAD: 03brlcad * r49246 10/brlcad/trunk/src/libbu/str.c: hard to call bu_strncasecmp() if it doesn't exist. fix typo.
18:28.41CIA-48BRL-CAD: 03brlcad * r49247 10/brlcad/trunk/src/conv/cy-g.c: convert instances of strncasecmp with bu_strncasecmp
19:07.17CIA-48BRL-CAD: 03brlcad * r49248 10/brlcad/trunk/src/libged/edit.c: comment tweak
19:08.04CIA-48BRL-CAD: 03brlcad * r49249 10/brlcad/trunk/src/fb/fbstretch.c: comment not useful
19:09.21CIA-48BRL-CAD: 03brlcad * r49250 10/brlcad/trunk/src/ (librt/search.c rt/read-rtlog.c): tweak comments regarding string comparisons
19:11.50CIA-48BRL-CAD: 03brlcad * r49251 10/brlcad/trunk/src/ (6 files in 5 dirs): use BU_STR_EQUAL() and bu_strcmp/bu_strncmp instead of strcmp/strncmp for more consistent and clear string comparison behavior
19:19.11CIA-48BRL-CAD: 03n_reed * r49252 10/brlcad/trunk/ (include/bu.h src/librt/opennurbs_ext.h): bu_sscanf should use scanf (not printf) syntax check. Substituted remaining instances of __BU* with _BU*.
19:56.39MaloeranThat question is going to look stupid, but is BRL-CAD supposed to run fine with --enable-optimized? Without it, my build of VSL runs fine. Otherwise, VSL crashes after some access to unitialized memory within BRL-CAD while opening a .g according to Valgrind
20:01.14CIA-48BRL-CAD: 03starseeker * r49253 10/brlcad/trunk/src/other/lemon/lempar.c: Bug in lemon parser template on Windows - we still need yyRuleName even when NDEBUG is defined.
20:02.49CIA-48BRL-CAD: 03bob1961 * r49254 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Fixed a bug in handleTreeSelect. Affected nodes not always getting highlighted when in this mode.
20:19.09``Erikit should, I'm seeing crashes related to bu_vls_snprintf() here :/
20:22.33CIA-48BRL-CAD: 03starseeker * r49255 10/brlcad/trunk/NEWS: Bob fixed a bug in Archer's tree view - the tree view wasn't highlighting the correct objects when the option was set to highlight objects that would be impacted by editing the currently selected object.
20:25.14MaloeranAh! So I'm not alone
20:27.44MaloeranErik, do you want to investigate these crashes? Or I could, but I'm sure you know BRL-CAD more than I do :)
20:29.02CIA-48BRL-CAD: 03brlcad * r49256 10/brlcad/trunk/regress/repository.sh: restructure so that we only walk the source hierarchy with find once. check for the other newer non-public headers (bin/bselect). stub in a new test for API usage.
20:31.39``ErikI have a fix for where I see it, but an older checkout already has it, need to investigate this a hair more
20:32.59CIA-48BRL-CAD: 03brlcad * r49257 10/brlcad/trunk/src/libged/simulate/simulate.c: eliminate dead commented-out code
20:35.08CIA-48BRL-CAD: 03erikgreenwald * r49258 10/brlcad/trunk/src/libged/red.c: Add bu_vls_init() to dynamically allocated vls. 49225 messed up by going a bit too wide.
20:35.38CIA-48BRL-CAD: 03brlcad * r49259 10/brlcad/trunk/src/ (5 files in 4 dirs): BU_STR_EQUAL() propagation
20:35.38MaloeranSo that was the fix?
20:35.42``Erikyeah
20:35.48``Erikfor the red command
20:35.51MaloeranCan you paste the few relevant  lines of code?
20:36.06``Erikit's highly likely that brlcad broke it several other places with his commit there... :D
20:36.14``Erikit was a missing bu_vls_init();
20:36.53``Erikbt the crash to before the bu_vls_snprintf() or whatever and verify the vls is getting an init call before trying to use it *shrug*
20:37.11*** join/#brlcad GhstWlf (d9d215e0@gateway/web/ajax/mibbit.com/session)
20:37.44``Erikmight be that lee did something silly like allocate and set the magic himself, instead of using the api... O.o I was seeing crashes in both debug and release
20:39.33MaloeranMy crash is definitely with vls strings
20:39.48MaloeranValgrind says some read memory is never initialized
20:40.04MaloeranSo yes, I'm pretty sure it was the same issue
20:44.05``ErikI'd guess that there're several places that now have this issue, we'll just have to fix them as we find them... and take away someones scripted code modification capabilities *cough* O:-)
20:44.50Maloeran:) Well I'll grab the latest SVN and let you know if that still crashes
20:45.06``ErikI doubt your thing would be using the red cmd from libged
20:45.39MaloeranAh. It's a db_update_nref() call reading a .g file that crashes in bu_vls_trimspace()
20:46.06MaloeranAnd it does so systematically. I just had a telecon with other people, and it works fine for everyone else but me
20:46.12MaloeranAlso, I'm the only one who compiled BRL-CAD with optimization
20:47.30``Erikdo you have a stack trace?
20:47.50MaloeranYes
20:48.28CIA-48BRL-CAD: 03starseeker * r49260 10/brlcad/trunk/src/conv/step/schema.cc: need bu.h here for BU_STR_EQUAL
20:48.31Maloeranhttp://www.rayforce.net/brlcadbug.txt
20:48.56MaloeranAny insight? I'm using BRL-CAD 7.20.4
20:50.26Maloeran(gdb) p *vp    $2 = {vls_magic = 2301836219, vls_str = 0x7fffcc002050 "R", vls_offset = 4294967296, vls_len = 140733193388072, vls_max = 140737028006102}
20:50.37MaloeranBut that memory is unitialized, says Valgrind
20:51.55MaloeranI'm downloading the SVN now just in case
20:52.36``Erikvls_lena nd vls_max are wayyy off
20:53.03MaloeranYup, the memory is unitialized, it's random garbage
20:54.19``Eriktrunk SHOULD work there, lemme look at 7.20.4
20:54.43MaloeranThanks
21:01.15``ErikO.O I'd almost think something is screwy with your strlen()... maybe break in bu_str_true(), set watches, and do line stepping to see what happens? cuz it SHOULD work fine
21:03.54MaloeranYeah... I was hoping to avoid debugging BRL-CAD, it involves figuring out a big chunk of code first
21:04.41``Eriknot really, it's all in libbu
21:10.04``Erikyeah, I'd guess there's an issue with your strlen() impl, your compiler or your gdb :/ I'd break bu_str_true and step it
21:10.48``Erikaccording to your gdb, you SHOULD be able to cause a crash with: int main(int argc, char **argv) { printf("%d\n", bu_str_true("R")); return 0; }
21:11.41``Erikmine prints 82 on an optimized build, like it should
21:11.53``Erik(and I even hopped on a 64b linux to test it)
21:12.48MaloeranThanks, I'm debugging
21:15.26``Erikhmmmm, does mged 'tops' work?
21:15.35CIA-48BRL-CAD: 03starseeker * r49261 10/brlcad/trunk/CMakeLists.txt: Don't squack about librtserver unless it was actually on to start with...
21:16.16Maloeran"Error: A database is not open!" ? :)
21:16.31``Erikyeah, it needs an open db... :D like ktank
21:17.18``Erik$ bin/mged share/brlcad/7.21.0/db/ktank.g tops
21:17.22MaloeranSeems to work with moss.g
21:17.41``Erikmebbe the .g file is mangled?
21:18.40MaloeranEverything seems to run fine. It may be more something like heap/stack corruption
21:22.55MaloeranI found the bug
21:23.33Maloeranlibbu/booleanize.c, should be    struct bu_vls vls = BU_VLS_INIT_ZERO;
21:23.43Maloeran7.20.4 has struct bu_vls vls;
21:23.46MaloeranTrunk is fine though
21:24.39MaloeranToo bad it's already fixed in trunk, I can't claim credits :p
21:26.14MaloeranPerfect, it doesn't crash anymore. Thanks Erik
21:28.24``Erikyes, but 7.20.4 had bu_vls_init(&vls);, which does the same thing :/ *shrug* as longa s it's fixed, I suppose
21:29.59MaloeranHum... Yes, quite
21:32.21MaloeranYou are right, this is quite strange, it doesn't appear to make sense
21:35.41MaloeranI put some printf() and it's definitely not cleared to zero after bu_vls_init(&vls); This almost looks like a compiler bug
21:38.55``Erikmakes ya a bit twitchy, looking at a possible compiler bug, no? ;0
21:38.57``Erik;)
21:39.21``Erikis libc going to puke? will the kernel spew random data across your inodes?
21:39.58MaloeranExamining flow, it doesn't actually go in bu_vls_init()
21:40.08MaloeranGrah screw that, I'm checking the assembly
21:43.43CIA-48BRL-CAD: 03starseeker * r49262 10/brlcad/trunk/src/librt/db5_types.c: Initialize endptr to NULL (Lee Butler)
21:47.19MaloeranCould there be a conflict for the symbol bu_vls_init? gdb gives me an address for symbol bu_vls_init that isn't the function
21:48.19MaloeranOh crap. VLS might have a bu_vls_init
21:49.38MaloeranYup! Conflict between the 2 symbols, the BRL-CAD libraries are calling the bu_vls_init() from VLS
21:53.30``Erikheh, that'd do it
21:54.04``Erikand your compiler didn't bark about symbol conflicts? -W -Wall -Werror -ansi -pedantic ... ?
21:55.34MaloeranApparently didn't. But it's a runtime symbol resolution conflict, not compilation time
21:56.15``Erikyou'd think it'd see it at link time unless once is being done through dlopen()
21:56.58MaloeranMy system might be setup in a non-typical way for that kind of stuff, I played with hijacking function calls from within libraries before
21:58.04``Erikviolently enough for it to stick? LD_PRELOAD not good enough? ;)
22:04.57MaloeranAh :), are you sure it's supposed to warn you when running a program with a symbol conflict?
22:05.23MaloeranLike if I write a program with a printf symbol, it's still going to compile  and run
22:06.37MaloeranWhy did Lee copy half of vls.c in VLS anyway
22:31.58brlcad``Erik: that wasn't one bit scripted
22:40.22brlcadquick to blame me for vague notions of bugs, eh?  that issue in red looks to be the only accidental init removal of a heap-allocated vls
22:43.44MaloeranI know it's far from your world, but do you guys know who is the lead developer for VSL?
22:46.14CIA-48BRL-CAD: 03n_reed * r49263 10/brlcad/trunk/src/libbu/sscanf.c: fix branching on unitialized value
22:46.21MaloeranI have no idea who to send bug reports to, like that symbol conflict. And Lee isn't very talkative by email.
22:48.41CIA-48BRL-CAD: 03brlcad * r49264 10/brlcad/trunk/src/libged/red.c: no, 49225 didn't go far enough. there is no reason for target_name to be allocated on the heap. put the caller on the stack and pass in a pointer in so we just print to it. simplifies the cleanup too.
22:49.19brlcadMaloeran: whomever gave you the source code would be my inclination
22:50.25MaloeranThat was Lee
22:50.31brlcadthere ya go ;)
22:50.37MaloeranDarn :)
22:50.57brlcadthere's actually vls.c source code in vsl?
22:51.40MaloeranYes, half of it, but it's not used anywhere. And it conflicted with BRL-CAD and caushed all my crashes.
22:51.59brlcadnods, symbol overrides are a bitch
22:52.14brlcadwe use that trick in a couple places in brl-cad intentionally
22:52.17brlcadit's ridiculous
22:52.35MaloeranI would rather use function pointers if you need that functionality
22:53.13brlcadI suspect he probably pulled in sources in order to use some basic brl-cad features he's familiar with without requiring all of brl-cad
22:53.16brlcads/all/any/
22:53.24*** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol)
22:53.38brlcadbut then later using more and more and eventually making it a dep, but not removing his copied source(s)
22:53.43MaloeranWell yes, except that code isn't used anywhere. It just made me lose 3 days of debugging
22:53.49MaloeranRight
22:58.26CIA-48BRL-CAD: 03brlcad * r49265 10/brlcad/trunk/regress/repository.sh:
22:58.26CIA-48BRL-CAD: add the beginnings of a new regression test for API usage to make sure that
22:58.26CIA-48BRL-CAD: common functions that libbu provides or wrapped are being used instead of their
22:58.26CIA-48BRL-CAD: non-libbu counterparts. we include exemptions for the implementation files that
22:58.26CIA-48BRL-CAD: wrap functions and tester applications that compare them to the libbu version.
22:58.27CIA-48BRL-CAD: since there are so many matches, though, don't let the test halt regression
22:58.28CIA-48BRL-CAD: until they're all taken care of.
22:58.39brlcadwoot, that's been a long time coming

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.