| 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 | ``Erik | huh, something kicked up on bz at 3:15 this morning, added ~30% cpu usage |
| 14:38.19 | brlcad | prolly someone browsing porn through a proxy |
| 14:50.13 | ``Erik | looks 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.44 | brlcad | looks like a couple bots are walking content at the moment |
| 15:34.57 | brlcad | http://www.globalspec.com/Ocelli being one, googlebot another |
| 16:41.43 | CIA-48 | BRL-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.44 | CIA-48 | BRL-CAD: 03starseeker * r49242 10/brlcad/trunk/src/other/CMakeLists.txt: |
| 16:50.45 | CIA-48 | BRL-CAD: INSTALL.new on CMake is different because we're not running the THIRD_PARTY |
| 16:50.45 | CIA-48 | BRL-CAD: macro for SCL on Windows. Try a different approach to disabling SCL with MSVC |
| 16:50.45 | CIA-48 | BRL-CAD: that should let the THIRD_PARTY macro run. This will be moot once we get SCL |
| 16:50.45 | CIA-48 | BRL-CAD: working with MSVC, and can go away then. |
| 17:28.46 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 17:33.57 | CIA-48 | BRL-CAD: 03brlcad * r49243 10/brlcad/trunk/ (doc/deprecation.txt include/bu.h src/libbu/str.c): |
| 17:33.57 | CIA-48 | BRL-CAD: header says null is a perfectly valid parameter to bu_strcmp() so there's no |
| 17:33.57 | CIA-48 | BRL-CAD: need to print it. so get rid of the label parameter since it's otherwise |
| 17:33.57 | CIA-48 | BRL-CAD: unused. that means the function can take on the macro name and the macro can go |
| 17:33.57 | CIA-48 | BRL-CAD: away. round out the offering with implementations for strncmp() and |
| 17:33.58 | CIA-48 | BRL-CAD: strncasecmp() too. |
| 17:37.10 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) | |
| 18:03.28 | CIA-48 | BRL-CAD: 03brlcad * r49244 10/brlcad/trunk/include/bu.h: eep, update the macros calls to bu_strcmpm() to bu_strcmp() |
| 18:04.14 | CIA-48 | BRL-CAD: 03brlcad * r49245 10/brlcad/trunk/include/bu.h: save the file, then commit |
| 18:10.56 | CIA-48 | BRL-CAD: 03brlcad * r49246 10/brlcad/trunk/src/libbu/str.c: hard to call bu_strncasecmp() if it doesn't exist. fix typo. |
| 18:28.41 | CIA-48 | BRL-CAD: 03brlcad * r49247 10/brlcad/trunk/src/conv/cy-g.c: convert instances of strncasecmp with bu_strncasecmp |
| 19:07.17 | CIA-48 | BRL-CAD: 03brlcad * r49248 10/brlcad/trunk/src/libged/edit.c: comment tweak |
| 19:08.04 | CIA-48 | BRL-CAD: 03brlcad * r49249 10/brlcad/trunk/src/fb/fbstretch.c: comment not useful |
| 19:09.21 | CIA-48 | BRL-CAD: 03brlcad * r49250 10/brlcad/trunk/src/ (librt/search.c rt/read-rtlog.c): tweak comments regarding string comparisons |
| 19:11.50 | CIA-48 | BRL-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.11 | CIA-48 | BRL-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.39 | Maloeran | That 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.14 | CIA-48 | BRL-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.49 | CIA-48 | BRL-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 | ``Erik | it should, I'm seeing crashes related to bu_vls_snprintf() here :/ |
| 20:22.33 | CIA-48 | BRL-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.14 | Maloeran | Ah! So I'm not alone |
| 20:27.44 | Maloeran | Erik, do you want to investigate these crashes? Or I could, but I'm sure you know BRL-CAD more than I do :) |
| 20:29.02 | CIA-48 | BRL-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 | ``Erik | I have a fix for where I see it, but an older checkout already has it, need to investigate this a hair more |
| 20:32.59 | CIA-48 | BRL-CAD: 03brlcad * r49257 10/brlcad/trunk/src/libged/simulate/simulate.c: eliminate dead commented-out code |
| 20:35.08 | CIA-48 | BRL-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.38 | CIA-48 | BRL-CAD: 03brlcad * r49259 10/brlcad/trunk/src/ (5 files in 4 dirs): BU_STR_EQUAL() propagation |
| 20:35.38 | Maloeran | So that was the fix? |
| 20:35.42 | ``Erik | yeah |
| 20:35.48 | ``Erik | for the red command |
| 20:35.51 | Maloeran | Can you paste the few relevant lines of code? |
| 20:36.06 | ``Erik | it's highly likely that brlcad broke it several other places with his commit there... :D |
| 20:36.14 | ``Erik | it was a missing bu_vls_init(); |
| 20:36.53 | ``Erik | bt 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 | ``Erik | might 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.33 | Maloeran | My crash is definitely with vls strings |
| 20:39.48 | Maloeran | Valgrind says some read memory is never initialized |
| 20:40.04 | Maloeran | So yes, I'm pretty sure it was the same issue |
| 20:44.05 | ``Erik | I'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.50 | Maloeran | :) Well I'll grab the latest SVN and let you know if that still crashes |
| 20:45.06 | ``Erik | I doubt your thing would be using the red cmd from libged |
| 20:45.39 | Maloeran | Ah. It's a db_update_nref() call reading a .g file that crashes in bu_vls_trimspace() |
| 20:46.06 | Maloeran | And it does so systematically. I just had a telecon with other people, and it works fine for everyone else but me |
| 20:46.12 | Maloeran | Also, I'm the only one who compiled BRL-CAD with optimization |
| 20:47.30 | ``Erik | do you have a stack trace? |
| 20:47.50 | Maloeran | Yes |
| 20:48.28 | CIA-48 | BRL-CAD: 03starseeker * r49260 10/brlcad/trunk/src/conv/step/schema.cc: need bu.h here for BU_STR_EQUAL |
| 20:48.31 | Maloeran | http://www.rayforce.net/brlcadbug.txt |
| 20:48.56 | Maloeran | Any insight? I'm using BRL-CAD 7.20.4 |
| 20:50.26 | Maloeran | (gdb) p *vp $2 = {vls_magic = 2301836219, vls_str = 0x7fffcc002050 "R", vls_offset = 4294967296, vls_len = 140733193388072, vls_max = 140737028006102} |
| 20:50.37 | Maloeran | But that memory is unitialized, says Valgrind |
| 20:51.55 | Maloeran | I'm downloading the SVN now just in case |
| 20:52.36 | ``Erik | vls_lena nd vls_max are wayyy off |
| 20:53.03 | Maloeran | Yup, the memory is unitialized, it's random garbage |
| 20:54.19 | ``Erik | trunk SHOULD work there, lemme look at 7.20.4 |
| 20:54.43 | Maloeran | Thanks |
| 21:01.15 | ``Erik | O.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.54 | Maloeran | Yeah... I was hoping to avoid debugging BRL-CAD, it involves figuring out a big chunk of code first |
| 21:04.41 | ``Erik | not really, it's all in libbu |
| 21:10.04 | ``Erik | yeah, 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 | ``Erik | according 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 | ``Erik | mine 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.48 | Maloeran | Thanks, I'm debugging |
| 21:15.26 | ``Erik | hmmmm, does mged 'tops' work? |
| 21:15.35 | CIA-48 | BRL-CAD: 03starseeker * r49261 10/brlcad/trunk/CMakeLists.txt: Don't squack about librtserver unless it was actually on to start with... |
| 21:16.16 | Maloeran | "Error: A database is not open!" ? :) |
| 21:16.31 | ``Erik | yeah, 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.22 | Maloeran | Seems to work with moss.g |
| 21:17.41 | ``Erik | mebbe the .g file is mangled? |
| 21:18.40 | Maloeran | Everything seems to run fine. It may be more something like heap/stack corruption |
| 21:22.55 | Maloeran | I found the bug |
| 21:23.33 | Maloeran | libbu/booleanize.c, should be struct bu_vls vls = BU_VLS_INIT_ZERO; |
| 21:23.43 | Maloeran | 7.20.4 has struct bu_vls vls; |
| 21:23.46 | Maloeran | Trunk is fine though |
| 21:24.39 | Maloeran | Too bad it's already fixed in trunk, I can't claim credits :p |
| 21:26.14 | Maloeran | Perfect, it doesn't crash anymore. Thanks Erik |
| 21:28.24 | ``Erik | yes, 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.59 | Maloeran | Hum... Yes, quite |
| 21:32.21 | Maloeran | You are right, this is quite strange, it doesn't appear to make sense |
| 21:35.41 | Maloeran | I 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 | ``Erik | makes ya a bit twitchy, looking at a possible compiler bug, no? ;0 |
| 21:38.57 | ``Erik | ;) |
| 21:39.21 | ``Erik | is libc going to puke? will the kernel spew random data across your inodes? |
| 21:39.58 | Maloeran | Examining flow, it doesn't actually go in bu_vls_init() |
| 21:40.08 | Maloeran | Grah screw that, I'm checking the assembly |
| 21:43.43 | CIA-48 | BRL-CAD: 03starseeker * r49262 10/brlcad/trunk/src/librt/db5_types.c: Initialize endptr to NULL (Lee Butler) |
| 21:47.19 | Maloeran | Could 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.19 | Maloeran | Oh crap. VLS might have a bu_vls_init |
| 21:49.38 | Maloeran | Yup! Conflict between the 2 symbols, the BRL-CAD libraries are calling the bu_vls_init() from VLS |
| 21:53.30 | ``Erik | heh, that'd do it |
| 21:54.04 | ``Erik | and your compiler didn't bark about symbol conflicts? -W -Wall -Werror -ansi -pedantic ... ? |
| 21:55.34 | Maloeran | Apparently didn't. But it's a runtime symbol resolution conflict, not compilation time |
| 21:56.15 | ``Erik | you'd think it'd see it at link time unless once is being done through dlopen() |
| 21:56.58 | Maloeran | My 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 | ``Erik | violently enough for it to stick? LD_PRELOAD not good enough? ;) |
| 22:04.57 | Maloeran | Ah :), are you sure it's supposed to warn you when running a program with a symbol conflict? |
| 22:05.23 | Maloeran | Like if I write a program with a printf symbol, it's still going to compile and run |
| 22:06.37 | Maloeran | Why did Lee copy half of vls.c in VLS anyway |
| 22:31.58 | brlcad | ``Erik: that wasn't one bit scripted |
| 22:40.22 | brlcad | quick 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.44 | Maloeran | I know it's far from your world, but do you guys know who is the lead developer for VSL? |
| 22:46.14 | CIA-48 | BRL-CAD: 03n_reed * r49263 10/brlcad/trunk/src/libbu/sscanf.c: fix branching on unitialized value |
| 22:46.21 | Maloeran | I have no idea who to send bug reports to, like that symbol conflict. And Lee isn't very talkative by email. |
| 22:48.41 | CIA-48 | BRL-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.19 | brlcad | Maloeran: whomever gave you the source code would be my inclination |
| 22:50.25 | Maloeran | That was Lee |
| 22:50.31 | brlcad | there ya go ;) |
| 22:50.37 | Maloeran | Darn :) |
| 22:50.57 | brlcad | there's actually vls.c source code in vsl? |
| 22:51.40 | Maloeran | Yes, half of it, but it's not used anywhere. And it conflicted with BRL-CAD and caushed all my crashes. |
| 22:51.59 | brlcad | nods, symbol overrides are a bitch |
| 22:52.14 | brlcad | we use that trick in a couple places in brl-cad intentionally |
| 22:52.17 | brlcad | it's ridiculous |
| 22:52.35 | Maloeran | I would rather use function pointers if you need that functionality |
| 22:53.13 | brlcad | I 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.16 | brlcad | s/all/any/ |
| 22:53.24 | *** part/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 22:53.38 | brlcad | but then later using more and more and eventually making it a dep, but not removing his copied source(s) |
| 22:53.43 | Maloeran | Well yes, except that code isn't used anywhere. It just made me lose 3 days of debugging |
| 22:53.49 | Maloeran | Right |
| 22:58.26 | CIA-48 | BRL-CAD: 03brlcad * r49265 10/brlcad/trunk/regress/repository.sh: |
| 22:58.26 | CIA-48 | BRL-CAD: add the beginnings of a new regression test for API usage to make sure that |
| 22:58.26 | CIA-48 | BRL-CAD: common functions that libbu provides or wrapped are being used instead of their |
| 22:58.26 | CIA-48 | BRL-CAD: non-libbu counterparts. we include exemptions for the implementation files that |
| 22:58.26 | CIA-48 | BRL-CAD: wrap functions and tester applications that compare them to the libbu version. |
| 22:58.27 | CIA-48 | BRL-CAD: since there are so many matches, though, don't let the test halt regression |
| 22:58.28 | CIA-48 | BRL-CAD: until they're all taken care of. |
| 22:58.39 | brlcad | woot, that's been a long time coming |