IRC log for #brlcad on 20101122

08:31.56*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
08:48.12*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
09:36.09*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
09:46.47*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
10:14.43*** join/#brlcad archivist_emc (~archivist@host217-34-113-62.in-addr.btopenworld.com)
10:31.26*** join/#brlcad mafm (~mafm@193.153.53.223)
10:42.12*** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1)
11:10.49d-loMernin all!
11:48.47*** join/#brlcad merzo (~merzo@193.254.217.44)
13:12.05CIA-55BRL-CAD: 03davidloman * r41411 10/rt^3/trunk/src/utility/Logger.cxx:
13:12.05CIA-55BRL-CAD: Break out conversion steps of ostringstream to c string by steps. Eliminated
13:12.05CIA-55BRL-CAD: warning: "format not a string literal and no format arguments" by passing in a
13:12.05CIA-55BRL-CAD: zero length string to bu_log. Hackish, but I don't know any other workaround
13:12.05CIA-55BRL-CAD: yet.
13:21.21CIA-55BRL-CAD: 03davidloman * r41412 10/rt^3/trunk/src/libNet/PortalManager.cxx: Make an implicit type conversion explicit. Makes newer compilers happy.
13:24.30CIA-55BRL-CAD: 03davidloman * r41413 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx: Downgrade the long to an int cause we don't need to use that much integer.
13:25.33CIA-55BRL-CAD: 03davidloman * r41414 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx: More making implicit type conversions explicit. Makes newer compilers happy.
13:37.03brlcadd-lo: bu_log("%s", out.str().c_str());
13:37.56brlcadthe first argument to bu_log/printf/fprintf/etc should be a constant string for security
13:39.08brlcadit was warning you about that because it's a security problem (and still is, even though you found a way to quiet the warning)
13:43.39d-loHrm, well I am passing in a const char*
13:44.19d-looh, heh, i get it.
13:44.20d-lonm
13:45.10CIA-55BRL-CAD: 03brlcad * r41415 10/brlcad/trunk/include/pkg.h: pks_title should be const. there's no intention to modify the title string.
13:45.23brlcadyeah, and those tiny two chars make a huge difference  :)
13:45.31CIA-55BRL-CAD: 03davidloman * r41416 10/rt^3/trunk/src/utility/Logger.cxx: Security fix to logger. Thanks brlcad!
13:45.45d-loI'd be intrested to sitdown and get into details as to how that's a security risk.
13:47.04d-lobrlcad: bu_exit() use the same kinda security thing?
13:47.05d-loaka
13:47.28d-lobu_exit(exitCode, "%s", textToPrint) ?
13:52.53``Erikunlimited vargs stuff is a vector for overflow exploits... why we like snprintf over sprintf, etc
13:53.26``Erikum, phrack had an article about it like 15 years ago, uh, hobbit wrote it I think, smashing the stack for profit and fun or something
13:55.12``Erikbtw, was chumming with a neighbor, handed me a can of 'four loco'... that shit is evil, don't touch it O.O
13:56.17``Erikdid some research this morning, 'blackout in a can' is one of the nicknames for the shit, they ain't jokin
13:56.54d-loyeah, there is some serious legal cases going on up here with that stuff.
13:57.06d-loall kinds of nastiness on the college campuses up here.
13:57.59d-locause we all know the end result of putting 'blackout' and 'college' together =D
13:58.30``Erikwas talking to my mom about it last night, she was bitching me all out about the thing, supposedly some nurse drank a can and was measuring blood pressure and pulse throughout and it went out the roof
14:05.09d-lowell yeah.  Its liquid downers and liquid uppers mixed in a can.  What else can you expect besides your body going ape-shit?
14:08.42d-loodd. I made the assumption bu_exit() would exit the application.  is that not a true-ism?
14:09.41d-loheh, nm.  Me being dumb, as usual.
14:12.30CIA-55BRL-CAD: 03davidloman * r41417 10/rt^3/trunk/src/libJob/JobManager.cxx: Put in some NULL checks for safety.
14:26.56``Erikbu_exit does some logging and then calls exit(2)
14:27.00``Erikiirc
14:27.18``Erikit should never return
14:27.46d-loyeah, I was a dum dum and accidentally re-inplemented exit().  caused an infinite loop =D
14:27.53``Erikahhh
14:27.58``Erik:)
14:28.11d-loyeah, that's be any my pal c/c++ =D
14:28.21d-lowow, I killed that one
14:28.31d-loyeah, that's me and my pals c/c++ =D
14:28.36``Erikyour grammar is... unique... like a c++ coder almost
14:28.47d-loyeah::almost!
14:29.24``ErikI'm almost scared of what'll happen when cliff and I coerce you into trying lithp :D
14:31.14d-lo=D
14:31.58d-loill \t likely \t start \t tab \t indenting \t things
14:32.22*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
14:32.41``Erikheh, that's python, lithp ith all parenthitheth
14:33.12d-loi thought listhp was indent based?
14:33.15``Eriknope
14:33.35d-lo:/
14:33.44``Erikindentation makes it readable, but it's almost like C, you can compact the program down to 1 long line if you want
14:33.53d-lowth am I remembering then....
14:33.57``Erikpython
14:34.09d-lono, something else
14:34.36``ErikI d'no, I think python is the only one that mandates indentation...
14:34.59``Erikthere've been several macro sets to replace parens with indentation for lisp...
14:35.04``Erikone of those, perhaps?
14:35.37d-lono idea.  I need to stop thinking. it hurts
15:03.05d-loI hate that.
15:03.33d-loThe moment after you step back from code for a few days, only to return, regain context and realize your design is all stupid.
15:03.37d-lo:/
15:26.10*** join/#brlcad merzo (~merzo@193.254.217.44)
15:45.47brlcadd-lo: sure, the details are pretty simple -- most functions that take variable-number-of-arguments (vargs) are potentially very risky, but the ones that take a "format string" ala printf(format,...) can be exceptionally dangerous
15:46.20brlcadbasically, they're pretty trivial to attack and abuse because of some of the % specifiers allow you to read/write memory
15:48.08brlcadso in the case of your code snippet, even though you passed a "const char *" .. constness is just a compiler hint, I can change that memory if I really want to, so I could change your string to be a "do something %evil" and take over the program
15:48.46brlcadso even when they're just strings you want to print, you still just make the format string just be a simple "%s" format string
15:48.54brlcadno vulnerability introduced
15:50.05brlcadd-lo: with the change I made to pkg.h, you should be able to undo the change you made in 41412
15:50.15brlcadcasting away constness isn't a good thing :)
15:50.23starseekerd-lo: that non-const string thing has bit me too :-)
15:53.29starseekerparticularly fun when you genuinely don't/can't know the length of the string you want to deal with in advance
16:00.48starseekerlast time I ran into it someone had a clever solution, but I can't find it in the logs right now :-(
16:03.14d-lobrlcad: ``Erik: does brlcad libs have a easy to use and fast byte buffer implementation?
16:08.21starseekerI usually end up falling back on bu_vls routines for strings
16:09.13d-lonah, looking for a transport mechanizim for bytes on/off a socket.
16:09.28d-loill look at vls though, might work
16:09.35starseekermaybe vlb?
16:09.42starseeker(varible lengty bytes, iirc?)
16:11.23d-loah ha.  you're correct!  vlb :)
16:14.32starseekerif indianla1ry is in, someone might point him to http://bzflag.bz/~starseeker/opennurbs-doxygen.tar.bz2 - dunno if he can use it or not, but might be worth a shot
16:14.52starseeker(probably better to download the tarball and expand locally - server would be slow for large pages)
16:16.20starseekerhad fixed headlight now and heads in
16:16.28starseekers/had/has/
16:39.40brlcadd-lo: yeah, for network stuff: vlb + htond, ntohd, htonl, htons, ntohl, ntohs
16:40.39brlcadfeel free to expand vlb if you need it to do something more.
16:42.53brlcadyou could also use a std::vector<char>
16:44.18d-loyeah, im looking for something thread safe, fast, lightwieght, etc.
16:44.44brlcadhard to beat a "char *buf" ;)
16:44.51d-loya I know :)
16:45.01d-lothe easy to use comes into play there :)
16:45.21d-lowas thinking about making a vlb class (for the sake of having that much more of a CPP api)
16:45.30d-loand they a reader/writer stream
16:45.51d-lobut vlb is pretty vanilla already
16:46.12brlcada class sounds like pure overhead on such a simple concept
16:46.46d-loquestion: vlb_magic: is that just data integrity stuff?
16:46.58brlcadyep, just like vls_magic
16:47.02d-lokk
16:47.13d-lostarts to understand MACROs.... scary!
16:49.03brlcadthe (only/main) reason vlb exists is to simplify memory management so the container can preallocate and auto-size as data is added/removed
16:49.22brlcadif your network buffers are fixed size, you should probably just use a plain array
16:49.42brlcadthe most simple solution wins
16:50.04d-loIm actually eyeballing the factory that deserializes the buffer into an object.
16:50.47d-loand, although nothing has caused us to hit a limit yet, I am realizing that Im going to need a decent sized buffer to handle some of the larger geometry chunks.
16:50.59d-loplus i just uncovered a stupid-ism in my design :)
16:51.24d-loand wanted to do a bit of homework on the 'bestest' buffer approach.
16:51.30brlcadnot following without looking at the code frankly, but..
16:52.02brlcadas long as any limits are well-documented, it shouldn't matter (until we hit the limit) so long as the design isn't so complex and integrated that it's painful to rework
16:52.14d-lookay, heres the simple.
16:52.24d-lonetwork socket offers up bytes
16:52.33brlcad*nod*
16:52.34d-lothey get accumulated in the NetMsgFactory until
16:52.53d-lothere is enough to deserialize into a NetMsg object (actually a subclass of, but whateva)
16:53.13d-loif that object is HUGE, like a BoT, then we could have issues
16:53.27d-loso I am thinking about planning ahead and use a variable sized buffer there.
16:53.44brlcadhow does the factory accumulate now?
16:53.57d-loit doesn't ":)  hence the flaw.
16:54.09brlcadno, it does "something" now with the data
16:54.12brlcadsome fixed buffer[BUFSIZE] array?
16:54.13d-loit was on the TODO list and somehow dropped off.
16:54.30*** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
16:54.43brlcad"they get accumulated" .. into what are they accumulated?
16:54.57d-lonope, the QByteArray that is filled from the socket.read() is passed directly into the deserialization routine.
16:55.14brlcadheh, so a QByteArray
16:55.20brlcadthat was the answer :P
16:55.22d-loif it fails, then the data is discarded.
16:55.28brlcadthe data is ALWAYS somewhere
16:56.05d-loAnd I like QByteArrays from an easy to use stand point, but I took a look at the source for them and they are pretty heavy wieght.
16:56.21d-loand Im trying to get in the habit of using a brlcad lib solution first :)
16:56.29d-loso Im shopping around for a buffer :)
16:56.36brlcadwhat's the limit you might run into?
16:56.57brlcadQByteArrays are undoubtedly variable-length no?
16:57.18d-lowell, the way I have it working now, the max socket buffer size is the max size of a NetMsg i can send.
16:57.28d-locause the Factory isn't accumulating anything.
16:57.30brlcadI like the idea switching to and/or expanding on a bu interface, but trying to understand the problem :)
16:57.43d-loyeah, the QByteArray is variable length
16:57.58d-lobut if i read the code right, the resizes are moderately expensive.
16:58.22brlcadany container that resizes is going to be expensive, no matter what
16:58.30brlcador it's just "not really resizing"
16:58.55d-loright on
16:59.07brlcadresize is a realloc or malloc+memcpy, so it's at least one system call
16:59.16brlcadminor minor in the big scheme of things
16:59.25brlcadcode maintenance should be the driver
16:59.43brlcadthe least complexity
16:59.51brlcadso anyways, back to the problem
17:00.11brlcadNetMsg does the network read?
17:00.15brlcadinto a fixed byte array?
17:00.31d-lookay, so from that angle, either a simple VLB object with the reader/writers built in OR a set of reader/writers that use bu_vlb structs....
17:00.46d-lookay, here's the sequence for a read
17:01.03d-loPortalManager maintains a thread that runs the select() call
17:02.04brlcadI'm on my way in, maybe better to explain in person? :)
17:02.09brlcadhears the furious typing
17:02.13d-lothere is a FD<->Portal map
17:02.17d-lois at home also :)
17:02.23brlcadah, okay, continue then :)
17:02.39d-loa portal is basically a fancy pkg_conn
17:02.43brlcadk
17:03.00brlcaddo portals do the read/write?
17:03.52d-loportals make the calls to libpkg.  libpkg does the read.write
17:04.05brlcadokay
17:05.09d-lobut libpkg's callback mechanism ultimately calls the NetMsgFactory.deserializeNetMsg()
17:05.28d-loand the buffer is deserialized there.  or atleast is attempted.
17:05.49d-loIm going to switch that out to an accumulation call instead of a deserial call.
17:06.07d-lothat way, if we haven't got all the bytes for the Msg yet, we can just try again later.
17:06.09brlcadso deserialize is called when a package arrives, each pkg package supposedly corresponds with a netmsg message, yes?
17:06.32d-locan't assure that, no
17:07.01d-losince everything I have done thus far is small-ish, they all fit into the socket's buffer.
17:07.18brlcadwhich buffer?
17:08.06brlcadyou said you feed a message to pkg, no?
17:08.16d-loone sec
17:08.17brlcadpkg does it's own rebuffering under the hood for the actual network send/recv, it's already decoupled
17:08.38brlcadpkg packages can be as large as you want
17:08.59brlcadit won't call the callback until all the data for a package is received
17:09.10d-lobased on the len in the pkg header?
17:09.16brlcadyeah
17:09.18d-lokk
17:09.40d-lothen theres another problem I have to address :/
17:09.59brlcadactually no, not the len in the header
17:10.09brlcadwhen you call pkg_send, you pass a buffer and a size
17:10.19brlcadthat buffer can be any size
17:11.07d-lothat size value is transmitted prior to the buffer?
17:12.19brlcadare you asking how pkg does what it does?  because that's pretty much irrelevant -- you feed it array with a size and tell it to send, it'll kick off the callback on the other side when that package is received (in full)
17:14.07brlcadthat's one of the main points of pkg, so you don't have to worry about parceling data, network buffer sizes, kernel socket buffer sizes, transmission failures, etc
17:16.03d-lojust verifying that the call back doesnt fire till the data is arrived in full
17:16.27brlcadif it does, it'd be a bug!
17:16.39d-loHrm, so it appears theres an issue with select then.
17:16.55d-logotta put my head back in the code.
17:16.59d-lobe back later ;)
17:17.03d-lothanks for the talk!
17:20.45brlcadgood luck
17:21.14brlcadyeah, pkg_process will only dispatch the callback if the package is fully received
17:35.21*** join/#brlcad mafm_ (~mafm@193.153.53.223)
19:47.24CIA-55BRL-CAD: 03starseeker * r41418 10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: Enhance the rtarea man page description of exposed and presented area.
20:26.52CIA-55BRL-CAD: 03starseeker * r41419 10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: rtarea does indeed present cumulative presented area, but it does not represent the presented area of a group.
20:48.26CIA-55BRL-CAD: 03starseeker * r41420 10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: Thanks Keith - make some changes, better examples for area.
21:57.09brlcadtodo needs updating..
21:57.29brlcadso are we going to have an end-of-november release posted?
21:59.03CIA-55BRL-CAD: 03brlcad * r41421 10/brlcad/trunk/TODO: solids_on_ray and ray pick menu option seems to be working just fine after the refactor changes.
22:05.42CIA-55BRL-CAD: 03brlcad * r41422 10/brlcad/trunk/TODO: merge tracking
22:06.49CIA-55BRL-CAD: 03brlcad * r41423 10/rt^3/trunk/src/libNet/PortalManager.cxx: do not cast away constness. fixed the pkg.h structure so that it specifies a const char * instead of a char *
22:42.56*** join/#brlcad ibot (~ibot@rikers.org)
22:42.56*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.16.10 is posted! (20100805)
23:30.35*** join/#brlcad ibot_ (~ibot@rikers.org)
23:30.35*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.16.10 is posted! (20100805)
23:33.33*** join/#brlcad ibot (~ibot@rikers.org)
23:33.33*** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.16.10 is posted! (20100805)
23:44.57CIA-55BRL-CAD: 03brlcad * r41425 10/brlcad/trunk/bench/run.sh: rename the benchmark log files by swapping benchmark and run so that they're more easily identified as benchmark*.log files or categorically as *run.log files so we can group outputs from other scripts/tools together.
23:51.10CIA-55BRL-CAD: 03brlcad * r41426 10/brlcad/trunk/sh/conversion.sh:
23:51.10CIA-55BRL-CAD: wrap a slew of boilerplate infrastructure similar to the benchmark suite so that
23:51.10CIA-55BRL-CAD: we have nice argument process, verbose/quiet options, help & instructions, and
23:51.10CIA-55BRL-CAD: clean formatted output. some basic adjustments made to use printf instead of
23:51.10CIA-55BRL-CAD: echo
23:55.58CIA-55BRL-CAD: 03brlcad * r41427 10/brlcad/trunk/sh/conversion.sh: use the same usage when no files are specified
23:56.14starseekerbrlcad: indianla1ry is working on getting his nurbs stuff in commit shape
23:56.41starseekerI think end of nov. is probably a safe prediction

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