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.49 d-lo Mernin all!
11:48.47 *** join/#brlcad merzo (~merzo@193.254.217.44)
13:12.05 CIA-55 BRL-CAD: 03davidloman * r41411 10/rt^3/trunk/src/utility/Logger.cxx:
13:12.05 CIA-55 BRL-CAD: Break out conversion steps of ostringstream to c string by steps. Eliminated
13:12.05 CIA-55 BRL-CAD: warning: "format not a string literal and no format arguments" by passing in a
13:12.05 CIA-55 BRL-CAD: zero length string to bu_log. Hackish, but I don't know any other workaround
13:12.05 CIA-55 BRL-CAD: yet.
13:21.21 CIA-55 BRL-CAD: 03davidloman * r41412 10/rt^3/trunk/src/libNet/PortalManager.cxx: Make an implicit type conversion explicit. Makes newer compilers happy.
13:24.30 CIA-55 BRL-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.33 CIA-55 BRL-CAD: 03davidloman * r41414 10/rt^3/trunk/tests/libpkgcpp/pkgcppTest.cxx: More making implicit type conversions explicit. Makes newer compilers happy.
13:37.03 brlcad d-lo: bu_log("%s", out.str().c_str());
13:37.56 brlcad the first argument to bu_log/printf/fprintf/etc should be a constant string for security
13:39.08 brlcad it 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.39 d-lo Hrm, well I am passing in a const char*
13:44.19 d-lo oh, heh, i get it.
13:44.20 d-lo nm
13:45.10 CIA-55 BRL-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.23 brlcad yeah, and those tiny two chars make a huge difference :)
13:45.31 CIA-55 BRL-CAD: 03davidloman * r41416 10/rt^3/trunk/src/utility/Logger.cxx: Security fix to logger. Thanks brlcad!
13:45.45 d-lo I'd be intrested to sitdown and get into details as to how that's a security risk.
13:47.04 d-lo brlcad: bu_exit() use the same kinda security thing?
13:47.05 d-lo aka
13:47.28 d-lo bu_exit(exitCode, "%s", textToPrint) ?
13:52.53 ``Erik unlimited vargs stuff is a vector for overflow exploits... why we like snprintf over sprintf, etc
13:53.26 ``Erik um, 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 ``Erik btw, 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 ``Erik did some research this morning, 'blackout in a can' is one of the nicknames for the shit, they ain't jokin
13:56.54 d-lo yeah, there is some serious legal cases going on up here with that stuff.
13:57.06 d-lo all kinds of nastiness on the college campuses up here.
13:57.59 d-lo cause we all know the end result of putting 'blackout' and 'college' together =D
13:58.30 ``Erik was 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.09 d-lo well yeah. Its liquid downers and liquid uppers mixed in a can. What else can you expect besides your body going ape-shit?
14:08.42 d-lo odd. I made the assumption bu_exit() would exit the application. is that not a true-ism?
14:09.41 d-lo heh, nm. Me being dumb, as usual.
14:12.30 CIA-55 BRL-CAD: 03davidloman * r41417 10/rt^3/trunk/src/libJob/JobManager.cxx: Put in some NULL checks for safety.
14:26.56 ``Erik bu_exit does some logging and then calls exit(2)
14:27.00 ``Erik iirc
14:27.18 ``Erik it should never return
14:27.46 d-lo yeah, I was a dum dum and accidentally re-inplemented exit(). caused an infinite loop =D
14:27.53 ``Erik ahhh
14:27.58 ``Erik :)
14:28.11 d-lo yeah, that's be any my pal c/c++ =D
14:28.21 d-lo wow, I killed that one
14:28.31 d-lo yeah, that's me and my pals c/c++ =D
14:28.36 ``Erik your grammar is... unique... like a c++ coder almost
14:28.47 d-lo yeah::almost!
14:29.24 ``Erik I'm almost scared of what'll happen when cliff and I coerce you into trying lithp :D
14:31.14 d-lo =D
14:31.58 d-lo ill \t likely \t start \t tab \t indenting \t things
14:32.22 *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
14:32.41 ``Erik heh, that's python, lithp ith all parenthitheth
14:33.12 d-lo i thought listhp was indent based?
14:33.15 ``Erik nope
14:33.35 d-lo :/
14:33.44 ``Erik indentation makes it readable, but it's almost like C, you can compact the program down to 1 long line if you want
14:33.53 d-lo wth am I remembering then....
14:33.57 ``Erik python
14:34.09 d-lo no, something else
14:34.36 ``Erik I d'no, I think python is the only one that mandates indentation...
14:34.59 ``Erik there've been several macro sets to replace parens with indentation for lisp...
14:35.04 ``Erik one of those, perhaps?
14:35.37 d-lo no idea. I need to stop thinking. it hurts
15:03.05 d-lo I hate that.
15:03.33 d-lo The 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.37 d-lo :/
15:26.10 *** join/#brlcad merzo (~merzo@193.254.217.44)
15:45.47 brlcad d-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.20 brlcad basically, they're pretty trivial to attack and abuse because of some of the % specifiers allow you to read/write memory
15:48.08 brlcad so 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.46 brlcad so 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.54 brlcad no vulnerability introduced
15:50.05 brlcad d-lo: with the change I made to pkg.h, you should be able to undo the change you made in 41412
15:50.15 brlcad casting away constness isn't a good thing :)
15:50.23 starseeker d-lo: that non-const string thing has bit me too :-)
15:53.29 starseeker particularly fun when you genuinely don't/can't know the length of the string you want to deal with in advance
16:00.48 starseeker last time I ran into it someone had a clever solution, but I can't find it in the logs right now :-(
16:03.14 d-lo brlcad: ``Erik: does brlcad libs have a easy to use and fast byte buffer implementation?
16:08.21 starseeker I usually end up falling back on bu_vls routines for strings
16:09.13 d-lo nah, looking for a transport mechanizim for bytes on/off a socket.
16:09.28 d-lo ill look at vls though, might work
16:09.35 starseeker maybe vlb?
16:09.42 starseeker (varible lengty bytes, iirc?)
16:11.23 d-lo ah ha. you're correct! vlb :)
16:14.32 starseeker if 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.52 starseeker (probably better to download the tarball and expand locally - server would be slow for large pages)
16:16.20 starseeker had fixed headlight now and heads in
16:16.28 starseeker s/had/has/
16:39.40 brlcad d-lo: yeah, for network stuff: vlb + htond, ntohd, htonl, htons, ntohl, ntohs
16:40.39 brlcad feel free to expand vlb if you need it to do something more.
16:42.53 brlcad you could also use a std::vector<char>
16:44.18 d-lo yeah, im looking for something thread safe, fast, lightwieght, etc.
16:44.44 brlcad hard to beat a "char *buf" ;)
16:44.51 d-lo ya I know :)
16:45.01 d-lo the easy to use comes into play there :)
16:45.21 d-lo was thinking about making a vlb class (for the sake of having that much more of a CPP api)
16:45.30 d-lo and they a reader/writer stream
16:45.51 d-lo but vlb is pretty vanilla already
16:46.12 brlcad a class sounds like pure overhead on such a simple concept
16:46.46 d-lo question: vlb_magic: is that just data integrity stuff?
16:46.58 brlcad yep, just like vls_magic
16:47.02 d-lo kk
16:47.13 d-lo starts to understand MACROs.... scary!
16:49.03 brlcad the (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.22 brlcad if your network buffers are fixed size, you should probably just use a plain array
16:49.42 brlcad the most simple solution wins
16:50.04 d-lo Im actually eyeballing the factory that deserializes the buffer into an object.
16:50.47 d-lo and, 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.59 d-lo plus i just uncovered a stupid-ism in my design :)
16:51.24 d-lo and wanted to do a bit of homework on the 'bestest' buffer approach.
16:51.30 brlcad not following without looking at the code frankly, but..
16:52.02 brlcad as 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.14 d-lo okay, heres the simple.
16:52.24 d-lo network socket offers up bytes
16:52.33 brlcad *nod*
16:52.34 d-lo they get accumulated in the NetMsgFactory until
16:52.53 d-lo there is enough to deserialize into a NetMsg object (actually a subclass of, but whateva)
16:53.13 d-lo if that object is HUGE, like a BoT, then we could have issues
16:53.27 d-lo so I am thinking about planning ahead and use a variable sized buffer there.
16:53.44 brlcad how does the factory accumulate now?
16:53.57 d-lo it doesn't ":) hence the flaw.
16:54.09 brlcad no, it does "something" now with the data
16:54.12 brlcad some fixed buffer[BUFSIZE] array?
16:54.13 d-lo it was on the TODO list and somehow dropped off.
16:54.30 *** join/#brlcad Ralith (~ralith@S010600221561996a.vc.shawcable.net)
16:54.43 brlcad "they get accumulated" .. into what are they accumulated?
16:54.57 d-lo nope, the QByteArray that is filled from the socket.read() is passed directly into the deserialization routine.
16:55.14 brlcad heh, so a QByteArray
16:55.20 brlcad that was the answer :P
16:55.22 d-lo if it fails, then the data is discarded.
16:55.28 brlcad the data is ALWAYS somewhere
16:56.05 d-lo And 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.21 d-lo and Im trying to get in the habit of using a brlcad lib solution first :)
16:56.29 d-lo so Im shopping around for a buffer :)
16:56.36 brlcad what's the limit you might run into?
16:56.57 brlcad QByteArrays are undoubtedly variable-length no?
16:57.18 d-lo well, the way I have it working now, the max socket buffer size is the max size of a NetMsg i can send.
16:57.28 d-lo cause the Factory isn't accumulating anything.
16:57.30 brlcad I like the idea switching to and/or expanding on a bu interface, but trying to understand the problem :)
16:57.43 d-lo yeah, the QByteArray is variable length
16:57.58 d-lo but if i read the code right, the resizes are moderately expensive.
16:58.22 brlcad any container that resizes is going to be expensive, no matter what
16:58.30 brlcad or it's just "not really resizing"
16:58.55 d-lo right on
16:59.07 brlcad resize is a realloc or malloc+memcpy, so it's at least one system call
16:59.16 brlcad minor minor in the big scheme of things
16:59.25 brlcad code maintenance should be the driver
16:59.43 brlcad the least complexity
16:59.51 brlcad so anyways, back to the problem
17:00.11 brlcad NetMsg does the network read?
17:00.15 brlcad into a fixed byte array?
17:00.31 d-lo okay, 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.46 d-lo okay, here's the sequence for a read
17:01.03 d-lo PortalManager maintains a thread that runs the select() call
17:02.04 brlcad I'm on my way in, maybe better to explain in person? :)
17:02.09 brlcad hears the furious typing
17:02.13 d-lo there is a FD<->Portal map
17:02.17 d-lo is at home also :)
17:02.23 brlcad ah, okay, continue then :)
17:02.39 d-lo a portal is basically a fancy pkg_conn
17:02.43 brlcad k
17:03.00 brlcad do portals do the read/write?
17:03.52 d-lo portals make the calls to libpkg. libpkg does the read.write
17:04.05 brlcad okay
17:05.09 d-lo but libpkg's callback mechanism ultimately calls the NetMsgFactory.deserializeNetMsg()
17:05.28 d-lo and the buffer is deserialized there. or atleast is attempted.
17:05.49 d-lo Im going to switch that out to an accumulation call instead of a deserial call.
17:06.07 d-lo that way, if we haven't got all the bytes for the Msg yet, we can just try again later.
17:06.09 brlcad so deserialize is called when a package arrives, each pkg package supposedly corresponds with a netmsg message, yes?
17:06.32 d-lo can't assure that, no
17:07.01 d-lo since everything I have done thus far is small-ish, they all fit into the socket's buffer.
17:07.18 brlcad which buffer?
17:08.06 brlcad you said you feed a message to pkg, no?
17:08.16 d-lo one sec
17:08.17 brlcad pkg does it's own rebuffering under the hood for the actual network send/recv, it's already decoupled
17:08.38 brlcad pkg packages can be as large as you want
17:08.59 brlcad it won't call the callback until all the data for a package is received
17:09.10 d-lo based on the len in the pkg header?
17:09.16 brlcad yeah
17:09.18 d-lo kk
17:09.40 d-lo then theres another problem I have to address :/
17:09.59 brlcad actually no, not the len in the header
17:10.09 brlcad when you call pkg_send, you pass a buffer and a size
17:10.19 brlcad that buffer can be any size
17:11.07 d-lo that size value is transmitted prior to the buffer?
17:12.19 brlcad are 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.07 brlcad that'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.03 d-lo just verifying that the call back doesnt fire till the data is arrived in full
17:16.27 brlcad if it does, it'd be a bug!
17:16.39 d-lo Hrm, so it appears theres an issue with select then.
17:16.55 d-lo gotta put my head back in the code.
17:16.59 d-lo be back later ;)
17:17.03 d-lo thanks for the talk!
17:20.45 brlcad good luck
17:21.14 brlcad yeah, 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.24 CIA-55 BRL-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.52 CIA-55 BRL-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.26 CIA-55 BRL-CAD: 03starseeker * r41420 10/brlcad/trunk/doc/docbook/system/man1/en/rtarea.xml: Thanks Keith - make some changes, better examples for area.
21:57.09 brlcad todo needs updating..
21:57.29 brlcad so are we going to have an end-of-november release posted?
21:59.03 CIA-55 BRL-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.42 CIA-55 BRL-CAD: 03brlcad * r41422 10/brlcad/trunk/TODO: merge tracking
22:06.49 CIA-55 BRL-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.57 CIA-55 BRL-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.10 CIA-55 BRL-CAD: 03brlcad * r41426 10/brlcad/trunk/sh/conversion.sh:
23:51.10 CIA-55 BRL-CAD: wrap a slew of boilerplate infrastructure similar to the benchmark suite so that
23:51.10 CIA-55 BRL-CAD: we have nice argument process, verbose/quiet options, help & instructions, and
23:51.10 CIA-55 BRL-CAD: clean formatted output. some basic adjustments made to use printf instead of
23:51.10 CIA-55 BRL-CAD: echo
23:55.58 CIA-55 BRL-CAD: 03brlcad * r41427 10/brlcad/trunk/sh/conversion.sh: use the same usage when no files are specified
23:56.14 starseeker brlcad: indianla1ry is working on getting his nurbs stuff in commit shape
23:56.41 starseeker I think end of nov. is probably a safe prediction

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