| --- Log opened Wed Aug 07 00:00:47 2013 |
| 00:00 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code |
| 00:03 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 00:05 | <&McMartin> | Those of you who use PuTTY |
| 00:05 | <&McMartin> | PuTTY did a security update today, fixing four bugs in its crypto implementations. |
| 00:06 | <&McMartin> | Xires: did you post a sample somewhere? I must have pinged out while you did so, if you did |
| 00:06 | <&McMartin> | (I'm mostly seeing disconn/reconn messages in backscroll) |
| 00:06 | < Xires> | McMartin; I have not, yet |
| 00:07 | <&McMartin> | OK, just checking |
| 00:07 | <&McMartin> | When you do, nickping; I don't have this window up front often |
| 00:08 | < Xires> | understood |
| 00:10 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 00:15 | | VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 00:19 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds] |
| 00:20 | | * simon_ ignores joins/parts on most networks |
| 00:43 | <@Reiv> | Crypto is one of those places you really want to have bug free. |
| 00:43 | <&McMartin> | Yeeeees. |
| 00:44 | <&McMartin> | And this has also pointedly revealed that PuTTY uses its own implementations of the algorithms. |
| 00:44 | < Azash> | Now, now McMartin |
| 00:44 | < Azash> | That whole school of thought about not writing your own implementation is for the skittish |
| 00:45 | <&McMartin> | Well, it depends on how good it is~ |
| 00:46 | <@Namegduf> | Does it? |
| 00:47 | <@Namegduf> | Or does it just embed a library which needed updating? |
| 00:47 | < Azash> | Still |
| 00:47 | <@Namegduf> | That's pretty much how you do things on Windows. |
| 00:47 | < Azash> | Wouldn't those libraries be provided by the OS? |
| 00:48 | <@Namegduf> | No. |
| 00:48 | <@Namegduf> | Windows doesn't do package management. |
| 00:48 | <&McMartin> | Er |
| 00:48 | <@Namegduf> | Shared libraries are a bigger threat from some stupid old version sitting around and supplanting your fixed one than they are a solution. |
| 00:48 | <&McMartin> | It kind of does, but it tries hard to hide it~ |
| 00:48 | | * simon_ didn't actually read about the bugfixes in specific, but assumes that the *use* of crypto libraries might just as well go wrong as implementing them. I also suppose there are two opposing interests: using the same libraries everywhere to maximize the likelihood of finding bugs, and using different libraries to minimize the likelihood of everyone being struck at once. |
| 00:48 | < Azash> | I know that but I would've thought that it offered at least basic tools that got updated with the rest |
| 00:48 | <@Namegduf> | Only if you write in C# |
| 00:49 | <@Namegduf> | And even then there's good reasons to reach out to third party implementations |
| 00:49 | <&McMartin> | Yeah, the .NET runtime is in Windows Update but for some insane reason the MSVC runtimes are not. |
| 00:49 | < Azash> | I suppose the easiest way to find out is to see whether the bug affected all versions of PuTTy or select OSes |
| 00:49 | <&McMartin> | All versions, but PuTTY is very, very windows specific even though a Unix version exists. |
| 00:49 | < Azash> | Ah |
| 00:50 | <&McMartin> | (Also, um, I'd have to check, but it's entirely possible Windows *didn't* have an exposed crypto library at the time of PuTTY's release) |
| 00:50 | <@Namegduf> | Or it doesn't have the right algorithms in. |
| 00:50 | <&McMartin> | Also possible; I recall XP required you to put in special packs for algos to get around export controls. |
| 00:50 | < Azash> | re. rolling your own, a crypto library is one of those "fun and informative to implement but never use it for anything" things |
| 00:51 | <@Namegduf> | It needs stuff that exactly matches what SSH servers routinely have. |
| 00:51 | < Azash> | Much like 3D engines and node.js services |
| 00:51 | <&McMartin> | Oh, um |
| 00:51 | <&McMartin> | PuTTY 0.45 was released in 1999. |
| 00:52 | <@Namegduf> | I think they get a pass for embedding a crypto library if that's what they did. |
| 00:52 | < Azash> | And even then it was software of a high calibre |
| 00:52 | < Xires> | McMartin; http://pastie.org/private/y6c69b4qseo5b0aqaag |
| 00:52 | <&McMartin> | Namegduf: Also, PuTTY is older than OpenSSH |
| 00:53 | <&McMartin> | That's a complete explanation in and of itself~ |
| 00:53 | <@TheWatcher> | From the FAQ page: " PuTTY is almost completely composed of code written from scratch for PuTTY. The only code we share with OpenSSH is the detector for SSH-1 CRC compensation attacks, written by CORE SDI S.A; we share no code at all with OpenSSL." |
| 00:53 | <@Namegduf> | Before McMartin's last line, I would have been willing to say that was terrible |
| 00:54 | | You're now known as TheWatcher[T-2] |
| 00:55 | <&McMartin> | Before I checked, me too~ |
| 00:55 | < simon_> | also, sharing code with OpenSSL is good? ;-) |
| 00:55 | <&McMartin> | Xires: The part I find most suspicious is the phrase &pp->dat |
| 00:55 | <&McMartin> | I would write &(pp->dat[0]) there. |
| 00:56 | < Xires> | K |
| 00:56 | < Xires> | I'm astonished at how the older code worked..much of that was copied more or less verbatim |
| 00:56 | <&McMartin> | Or just pp->dat alone, but I usually only do that when passing to something like strcmp |
| 00:56 | <&McMartin> | Yeah, it's possible that this is actually getting burned by some kind of padding issue. |
| 00:57 | <&McMartin> | You may need some #pragma pack shenanigans here |
| 00:59 | < Xires> | McMartin; http://pastie.org/private/lrb15pxwzbrvihlokipcaq - I'd forgotten to include struct ip_t for the summary |
| 01:00 | <&McMartin> | OK, ip_t is gonna be *wildly* different between 32- and 64-bit versions |
| 01:00 | < simon_> | was it someone on here who linked to HTTPS having a vulnerability? http://www.kb.cert.org/vuls/id/987798 |
| 01:01 | <&McMartin> | Xires: Do you happen to know if this stub code you wrote works on 32- and 64-bit? |
| 01:01 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 01:02 | < Xires> | McMartin; I've not compiled this piece by itself..only threw it together & ripped out anything that might violate my NDA |
| 01:02 | <&McMartin> | (In particular, if you're doing any casting of these values to things from a network source, that's going to be utterly disastrous on a machine with the wrong bit width unless you include directives like #pragma pack(1)) |
| 01:02 | < Xires> | but the rest of the code does indeed compile both 32- & 64-bit |
| 01:03 | <&McMartin> | Compile, yes; *run* is the trick~ |
| 01:06 | < Xires> | McMartin; runs on both 32- & 64-bit equally |
| 01:06 | < Xires> | all the same features work..all the same problems occur |
| 01:07 | <&McMartin> | Mmmm |
| 01:07 | < Xires> | neither is more or less stable and neither produces a problem that the other doesn't exhibit |
| 01:07 | | * McMartin nods |
| 01:07 | <&McMartin> | OK |
| 01:07 | < Xires> | nor does either one work where the other doesn't |
| 01:07 | <&McMartin> | I think your best next move is to run your real code under valgrind |
| 01:07 | <&McMartin> | valgrind detects buffer blowouts as they occur |
| 01:07 | < Xires> | also, sizeof(ip_t) between 32- & 64-bit reports the same 20 bytes |
| 01:08 | < Xires> | valgrind & mudflap have not been helpful to me |
| 01:08 | < Xires> | and efence has been virtually useless |
| 01:08 | <&McMartin> | efence is stack-only and this is heap corruption of some kind, so that makes sents |
| 01:08 | <&McMartin> | *sense |
| 01:09 | <&McMartin> | Anyway |
| 01:09 | | You're now known as TheWatcher[zZzZ] |
| 01:10 | <&McMartin> | The only way I can see this exploding in your face is if (a) struct pcap_pkthdr has a different packing discipline than pkt_t (unlikely) |
| 01:10 | < Xires> | McMartin; so it was ln#128 that you said would be better as &(pp->dat[0]) ? |
| 01:10 | <&McMartin> | Or if the "b" argument isn't at least 69 bytes long. |
| 01:10 | <&McMartin> | Yes. |
| 01:10 | <&McMartin> | The usage in #126 is what I would expect to see. |
| 01:11 | < Xires> | understood |
| 01:12 | <&McMartin> | It's possible that they're equivalent, but I don't trust C that far~ |
| 01:12 | < Xires> | I understand |
| 01:13 | < Xires> | I saw them as equivalent but I'm kinda doubting everything right now |
| 01:13 | <&McMartin> | To be clear: The intent is to interpret the first N bytes of the "dat" stuff just copied in in line 126 as an ether_hdr_t? |
| 01:14 | <&McMartin> | And not to rip a pointer out of the first 4/8 bytes and use *that* as one? |
| 01:16 | <&McMartin> | (I hope it's the former; the latter is unpleasantry even to my twisted mind) |
| 01:17 | < Xires> | from my understanding of the code; the intent is, unfortunately, the latter |
| 01:17 | <&McMartin> | OK |
| 01:17 | <&McMartin> | My first reaction is "I don't actually believe you" |
| 01:18 | <&McMartin> | If the thing being memcpy'd in is an ether_hdr_t, that's evidence that the intent is the former |
| 01:18 | < Xires> | well, in this specific function, the code actually only appears to do reads, not writes |
| 01:19 | <&McMartin> | Right; I'm just counting levels of indirection here. The #126 usage is equivalent to C++'s reinterpret_cast<>. |
| 01:19 | <&McMartin> | And this kind of thing is the sort of place you'd use that |
| 01:20 | < Xires> | I think I'd prefer, just for clarity, to make the ipp variable 'const' |
| 01:20 | < Xires> | though, ipp isn't just a cast of pp->dat but pp->dat[14] |
| 01:20 | < Xires> | 14 bytes into the dat structure |
| 01:21 | < Xires> | s/structure/buffer/ |
| 01:21 | | * McMartin nods |
| 01:21 | <&McMartin> | *that* operation is dangerous as Hell. |
| 01:21 | < Xires> | indeed |
| 01:21 | <&McMartin> | The safest way to handle that is not to count bytes, but to cast it to a properly organized structure and do field dereferences. |
| 01:21 | < Xires> | particularly since it's done with a calloc()'d parent buffer |
| 01:21 | <&McMartin> | That improves things slightly; calloc() is the one that properly memsets it to 0 before returning it, right? |
| 01:22 | < Xires> | only after the ipp pointer is established is data written to pp->dat[0] |
| 01:22 | <&McMartin> | As opposed to being Literally ANything |
| 01:22 | < Xires> | via the memcpy() on ln#126 |
| 01:22 | < simon_> | McMartin, that's what I recall. |
| 01:23 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 01:23 | <&McMartin> | Xires, the ipp init is fine |
| 01:23 | <&McMartin> | It's equivalent to pp->dat + sizeof(ether_hdr_t) |
| 01:23 | < Xires> | yes, as noted on ln#92, g_slice_alloc0() essentially does a calloc(), using memset() to clear the buffer before returning the pointer |
| 01:24 | <&McMartin> | Oh! |
| 01:24 | <&McMartin> | I know a good sanity check |
| 01:24 | <&McMartin> | After the *first* memcpy |
| 01:24 | <&McMartin> | check h and pp's corresponding fields, one by one |
| 01:24 | <&McMartin> | Make sure they match up |
| 01:24 | <&McMartin> | If there's some kind of structure layout glitch, they won't. |
| 01:24 | < Xires> | all of them? |
| 01:25 | < Xires> | is this something just for debug or are you suggesting it be in the release as well? |
| 01:25 | <&McMartin> | Just for debug |
| 01:25 | <&McMartin> | If you get "impossible" answers, that means you should probably start dumping the various offsets of all the fields to see what's changing |
| 01:25 | < Xires> | K..just a note; this is meant for packet capture code on 10 Gbit lines so I'm trying to keep expensive operations to a minimum, if possible |
| 01:26 | <&McMartin> | Right |
| 01:26 | <&McMartin> | This is code for determining "will this *ever* work" |
| 01:26 | < Xires> | well, in gdb, I do check that pp->hdr & h match |
| 01:26 | <&McMartin> | If you were to deploy it you'd actually put it as a test module outside of the core code. |
| 01:27 | < Xires> | though, not at every iteration |
| 01:27 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.] |
| 01:27 | <&McMartin> | The *really* important value here is caplen |
| 01:28 | <&McMartin> | caplen should be the minimum of snap (69) or h->caplen |
| 01:29 | < Xires> | and check that the strlen(b) >= 69? |
| 01:29 | <&McMartin> | strlen looks for nulls, I don't know the problem domain well enough to know if that's the mechanism, but it may not be |
| 01:29 | <&McMartin> | It needs to be >= caplen, though, not 69 |
| 01:29 | < Xires> | sz = strlen(b); snap = (sz < 69) ? sz : 69; ? |
| 01:29 | <&McMartin> | If caplen < 69, b only needs to be *that* long. |
| 01:30 | | Derakon[AFK] is now known as Derakon |
| 01:30 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code |
| 01:30 | <&McMartin> | Also |
| 01:30 | <&McMartin> | Line 128 is just generally scary |
| 01:31 | <&McMartin> | Do you know if that branch is being taken? |
| 01:31 | <&McMartin> | And if so, if ipp is being properly adjusted |
| 01:31 | < Xires> | it is, occasionally, being taken |
| 01:31 | < Xires> | and it does appear that it is correctly increasing the pointer by 2 bytes |
| 01:31 | <&McMartin> | Good. I was pretty sure it would do that |
| 01:32 | <&McMartin> | The next question is if *ipp is full of nonsense or not |
| 01:32 | < Xires> | though I would like to get rid of that strict aliasing warning |
| 01:32 | <&McMartin> | I'm not immediately familiar with that warning; can you quote it? |
| 01:33 | <&McMartin> | (also for god's sake put the consequent on its own line) |
| 01:33 | <&McMartin> | (That will also let you breakpoint exactly when the branch is taken) |
| 01:34 | <&McMartin> | Oh right, also |
| 01:34 | <&McMartin> | is "b" data coming in off the wire, untransformed? |
| 01:35 | | Karono_ [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 01:36 | <&McMartin> | Because if so that sets off all my bitwidth alarm bells |
| 01:36 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [NickServ (GHOST command used by Karono_)] |
| 01:36 | | Karono_ is now known as Karono |
| 01:36 | <&McMartin> | (And would mean the problem will manifest as nonsense filling up the pkt_t over the course of lines 130-136) |
| 01:36 | < Xires> | McMartin; "warning: dereferencing type-punned pointer will break strict-aliasing rules" |
| 01:36 | | * McMartin nods |
| 01:37 | < Xires> | yes, 'b' is a selection of bytes directly from the packet off the wire |
| 01:37 | <&McMartin> | OK, in order |
| 01:37 | <&McMartin> | I think you can eradicate that warning by replicating the logic from line 119 but with a + 2 at the end |
| 01:38 | < Xires> | K |
| 01:38 | <&McMartin> | Casting from raw data like that is very hazardous but if you're sufficiently strapped for speed you may have no choice but to do that instead of using custom marshallers |
| 01:39 | < Xires> | unfortunately, duplicating that logic does not eradicate the warning |
| 01:39 | <&McMartin> | Next step is to hand-disassemble b's contents (strlen *will not work* here, incidentally; you've got shorts so any short less than 256 will falsely trigger end-of-string) and compare it against *ipp at line 130. |
| 01:39 | <&McMartin> | Interesting. |
| 01:41 | < Xires> | 'tis alright, I can deal with that later |
| 01:41 | < Xires> | more concerned with the other issues, ATM |
| 01:41 | <&McMartin> | ...maybe not |
| 01:41 | <&McMartin> | Try compiling with -fno-strict-aliasing |
| 01:42 | <&McMartin> | I'm seeing some hints that this warning means "if you have -O2 or higher on, the compiler may produce incorrect code" |
| 01:43 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code |
| 01:43 | <&McMartin> | Another thing to attempt would be to replace the unsigned char with just a char, but that may be a gcc-specific hack |
| 01:43 | <&McMartin> | (-fno-strict-aliasing may seriously impact performance) |
| 01:44 | < Xires> | McMartin; okay, libpcap denotes that it sets the pcap_pkthdr.caplen to the size of b |
| 01:44 | < Xires> | or otherwise guarantees that pcap_pkthdr.caplen is the correct size of b |
| 01:44 | <&McMartin> | OK, that part is fine then |
| 01:44 | <&McMartin> | I'd move on to checking *ipp, at the point where the rest of the pkt_t is assigned from its values |
| 01:45 | <&McMartin> | If those offsets don't work out those'll get disastrous garbage |
| 01:45 | < Xires> | so the logic of using snap or caplen, whichever is smaller, should work |
| 01:45 | <&McMartin> | Excellent |
| 01:45 | | VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 01:46 | <&McMartin> | Anyway, that warning is apparently quite alarming from some searches on it |
| 01:46 | <&McMartin> | And I say this as someone who type-puns with great ruthlessness |
| 01:46 | <&McMartin> | And I don't get it in my own code -_- |
| 01:46 | <&McMartin> | (It might be worth replacing those instances of "unsigned char" with "char" in the structure definitions) |
| 01:47 | < Xires> | perhaps I should just create a new variable to point directly to pp->dat[0] and test from there? |
| 01:47 | <&McMartin> | Also worthwhile, but I expect that to match b precisely |
| 01:47 | < Xires> | I think the line is related to the the 'if' condition, not the ipp assignment |
| 01:47 | <&McMartin> | It's the interpretation starting at line 130 that's the problem. |
| 01:47 | <&McMartin> | Er |
| 01:47 | <&McMartin> | That I suspect may be the problem |
| 01:49 | <&McMartin> | The part that's interesting here is the line "it is always assumed that char* aliases other types" |
| 01:49 | <&McMartin> | I wonder if that means it is not true for unsigned char *. |
| 01:49 | <&McMartin> | (But that's also another reason to not have test and consequent on the same line) |
| 01:51 | <&McMartin> | See: http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule |
| 01:51 | <&McMartin> | This also includes links to other things that are likely to Be Problems for you at the end. |
| 01:51 | <&McMartin> | The code is explicitly dealing with endianness; packing is the part that worries me the most about what you've pasted. |
| 01:52 | < Xires> | indeed, endianness is handled in multiple different sections, in different ways |
| 01:53 | < Xires> | part of the reason for the cidr_t is to switch addresses to the correct endianness |
| 01:53 | | * McMartin nods |
| 01:53 | <&McMartin> | That said, the link regarding packing is not true anymore~ |
| 01:53 | <&McMartin> | http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html |
| 01:53 | < Xires> | familiar w/ that link |
| 01:53 | <&McMartin> | k |
| 01:54 | <&McMartin> | I didn't see them used in the paste which would make 32- and 64-bit object files possibly behave very differently |
| 01:55 | <&McMartin> | http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasi ng.html is also pretty good |
| 01:56 | < Xires> | does it help that this code is never expected to run on Windows? |
| 01:56 | <&McMartin> | At this level? I don't think so; this all looks pretty os-neutral |
| 01:56 | <&McMartin> | It might help if it's never expected to run on anything that isn't x86 or x86_64 |
| 01:57 | < Xires> | that too |
| 01:57 | < Xires> | it will only ever be Linux x86[_64] |
| 01:57 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds] |
| 01:58 | <&McMartin> | Then that is unlikely to help much, I'm afraid >_> |
| 01:58 | <&McMartin> | Because the pain comes in the 32-64 hop, which will modify structure offsets |
| 01:59 | < Xires> | K |
| 02:01 | < Xires> | so, then, the aliasing warning is symptom of improper handling of the data, resulting in part of the behavior? |
| 02:01 | <&McMartin> | Possible but not guaranteed |
| 02:01 | <&McMartin> | It's an indication that you're doing something potentially non-portable |
| 02:01 | < Xires> | wouldn't that cause different errors to be found between the systems? |
| 02:02 | <&McMartin> | However! You only have two platforms you care about, so that solves that, more or less |
| 02:02 | <&McMartin> | Depends. |
| 02:02 | <&McMartin> | You're getting a report of "wild memory corruption" |
| 02:02 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 02:02 | <&McMartin> | If it reaches that point by different ways, then that doesn't really change the symptom |
| 02:02 | < Xires> | yes |
| 02:02 | < Xires> | things break that normally shouldn't break |
| 02:02 | < Xires> | that have no reason for breaking |
| 02:02 | <&McMartin> | Does it break for both 32 and 64 bit or just for 64? |
| 02:02 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 02:03 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 02:03 | < Xires> | wild malloc() errors that crop up here & there causing anything from SIGSEGV to SIGABRT |
| 02:03 | < Xires> | both |
| 02:03 | < Xires> | both break in the same [numerous] places |
| 02:03 | < Xires> | with the same reasonings |
| 02:03 | < Xires> | with the same amount of randomness |
| 02:04 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 02:04 | < Xires> | sometimes the process will crash at the end of the hour..other times it'll run for 8 hours without a hitch and then die |
| 02:04 | | * McMartin nods |
| 02:05 | <&McMartin> | If you're sure this is the source, I'd start putting in paranoia checks to make sure that values haven't changed mysteriously somehow |
| 02:05 | < Xires> | sometimes it crashes when calling free() to free a correctly malloc()'d buffer in something completely unrelated |
| 02:05 | <&McMartin> | If it's failing *inside malloc* that may be a sign of a double free() |
| 02:06 | <&McMartin> | Which will corrupt the arena |
| 02:11 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 02:14 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has quit [Ping timeout: 121 seconds] |
| 02:15 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds] |
| 02:15 | <&McMartin> | "The last member of a structure with more than one named member may have incomplete array type; such a structure shall not be a member of a structure or an element of an array." |
| 02:15 | | Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has joined #code |
| 02:15 | | mode/#code [+o Reiv] by ChanServ |
| 02:15 | < Xires> | McMartin; alright, I removed the strict-aliasing warning |
| 02:15 | <&McMartin> | If the code you're looking at has every worked, anywhere, ever, the dat field is not your problem |
| 02:16 | <&McMartin> | Oho? How'd you manage it? |
| 02:17 | < Xires> | ether_hdr_t *eh = (ether_hdr_t) &(pp->dat[0]); ip_t *ipp = (ip_t*) ((unsigned char*) eh + sizeof(ether_hdr_t)); |
| 02:18 | <&McMartin> | OK, that looks good |
| 02:19 | <&McMartin> | What is the change that caused everything to start breaking? I got the impression this was a port. |
| 02:19 | <&McMartin> | Was it shifting to a new glibc? |
| 02:19 | < Xires> | then later, if (eh->ether_type == ETHERTYPE_8021Q) ipp = (ip_t*) ((unsigned char*) ipp + 2); |
| 02:19 | < Xires> | not glibc, glib2..different things |
| 02:19 | <&McMartin> | Aha, OK |
| 02:20 | < Xires> | glibc is the C library implementation that you're probably familiar with..glib2 is a utility API collection to help w/ portability & what-not |
| 02:21 | < Xires> | glib2 is what gtk uses to be architecture & platform-independent, basically |
| 02:21 | < Xires> | or, rather..not "independent" |
| 02:21 | < Xires> | but...I think you get the meaning |
| 02:22 | <&McMartin> | Right right |
| 02:22 | <&McMartin> | I misread or misremembered what you'd said |
| 02:22 | <&McMartin> | If it were a new libc, then malloc or free themselves might have changed |
| 02:23 | <&McMartin> | I wonder if glib2 has new invariants that are being violated somehow |
| 02:23 | <&McMartin> | Other than that, I'm tapped out. Sorry. =( |
| 02:24 | <&McMartin> | All I can say is that this part of the code looks pretty clean |
| 02:24 | < Xires> | well, that's delightful |
| 02:25 | | * McMartin has no experience with glib2 |
| 02:26 | <&McMartin> | As a fellow C/C++ programmer, sadface highfive for "bummer, this code works" |
| 02:26 | < Xires> | many thanks |
| 02:27 | < Xires> | glib2 is stable enough that I can reliably say that it is EXTREMELY unlikely to be a fault in glib2 |
| 02:27 | < Xires> | and most of the stuff I'm using is easily broken down |
| 02:28 | | Derakon is now known as Derakon[AFK] |
| 02:31 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 02:31 | <&McMartin> | Right |
| 02:31 | <&McMartin> | I didn't mean to imply "bug in glib2" |
| 02:32 | <&McMartin> | I meant more along the lines of "bug in your code that uses glib2, of the form 'causes undefined behavior'" |
| 02:32 | < Xires> | understood |
| 02:32 | <&McMartin> | That happened to be harmless in the old version but corrupts the heap in the new one |
| 02:32 | <&McMartin> | In my (limited, since the universe here is gigantic) experience that's most often caused by freeing the same pointer twice |
| 02:33 | | Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has joined #code |
| 02:39 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 02:39 | | mode/#code [+o himi] by ChanServ |
| 02:41 | < Xires> | McMartin; looking at the code as posted.. |
| 02:43 | < Xires> | sorry for delay, wife going crazy |
| 02:43 | <&McMartin> | No worries |
| 02:43 | < Xires> | anywho..with the code as posted can you tell me the correct size to free? |
| 02:44 | <&McMartin> | free doesn't require a size |
| 02:44 | <&McMartin> | It pulls it out of some metadata |
| 02:44 | < Xires> | g_slice_free1() does |
| 02:44 | <&McMartin> | oho |
| 02:44 | < Xires> | void g_slice_free1 (gsize block_size, |
| 02:44 | < Xires> | gpointer mem_block); |
| 02:44 | <&McMartin> | Eek |
| 02:44 | <&McMartin> | That's above my pay grade, I fear |
| 02:44 | <&McMartin> | I've never used that library, so I do not know |
| 02:45 | < Xires> | are you familiar with slab allocator? |
| 02:45 | <&McMartin> | Yes; written a few in my day |
| 02:45 | <&McMartin> | But that doesn't mean I know what the requirements are for this particular implementation |
| 02:45 | < Xires> | that's fine, I can explain enough of it..unless you've no interest |
| 02:46 | < Xires> | I've taken up quite a bit of your time..I'm thankful for all the advice & direction that you've provided |
| 02:47 | <&McMartin> | I'm kinda curious, but my guess is "that value has to be the same as the one you pass to the allocator" |
| 02:47 | < Xires> | 'tis what I figured..wanted to make sure that nothing in mkpp() was changing that |
| 02:47 | < Xires> | I really wouldn't think so |
| 02:48 | <&McMartin> | Yeah, me either |
| 02:48 | <&McMartin> | Ugh, if it's slab does it not accept arbitrary values for block_size |
| 02:51 | < Xires> | well, it's allocated with (sizeof(pkt_t) + 1542) and freed as g_slice_free1((sizeof(pkt_t) + 1542), pp); |
| 02:51 | < Xires> | so same size allocation & free |
| 02:51 | | * McMartin nods |
| 02:52 | <&McMartin> | I bet that's why valgrind is useless |
| 02:52 | < Xires> | quite possibly |
| 02:52 | < Xires> | hadn't thought of it 'til just a moment ago |
| 02:52 | <&McMartin> | I worry about double-free |
| 02:52 | <&McMartin> | slab allocators tend to recycle memory without actually free() ing it |
| 02:52 | < Xires> | indeed |
| 02:52 | <&McMartin> | Ha ha, oh man, that would be evil on a stick |
| 02:53 | <&McMartin> | You could #define away the slice operations to make them truly be calloc and free, and then valgrind *that* |
| 02:53 | < Xires> | I'll check to make sure that I don't free a section, like pp->dat, and then free pp later |
| 02:53 | < Xires> | glib2 allows you to essentially bypass the slab allocator via environment variable |
| 02:53 | < Xires> | G_SLICE=always-malloc |
| 02:53 | < Xires> | just uses malloc() |
| 02:54 | <&McMartin> | Eep |
| 02:54 | < Xires> | and g_slice_alloc0() will continue to memset to 0 |
| 02:54 | <&McMartin> | If you free a section that isn't the top that might break the shit out of things |
| 02:54 | <&McMartin> | (Maybe not if the slab allocator is cunning) |
| 02:54 | < Xires> | indeed |
| 02:54 | < Xires> | ah, I remember why I suspected mkpp... |
| 02:54 | <&McMartin> | But I'm pretty sure the rule with malloc and free is that you only get to free things returned by malloc, exactly, and that exactly once. |
| 02:55 | <&McMartin> | If you don't do that, subsequent calls to malloc may fail horribly |
| 02:55 | | Derakon[AFK] is now known as Derakon |
| 02:55 | < Xires> | running in gdb w/ mudflap, I see lots of issues where the calling function, the pcap_handler function, is denoted as having a 'violation'(thousands of them) on the line calling mkpp |
| 02:55 | | ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has quit [[NS] Quit: ZNC - http://znc.in] |
| 02:55 | <&McMartin> | Aha |
| 02:56 | < Xires> | "nearby object 1: checked region begins 2201B after and ends 2204B after" "nearby object 2: checked region begins 528B before and ends 525B before" |
| 02:56 | | ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has joined #code |
| 02:56 | | mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ |
| 02:56 | <&McMartin> | Hrm. |
| 02:57 | <&McMartin> | Yeah, I've never used mudflap either, I fear I can't interpret that |
| 02:57 | <&McMartin> | I wonder if it's somethign right before this call, though |
| 02:59 | < Xires> | while (hook) { [[\n]] hook->data = mkpp(hdr, b, cnt); |
| 02:59 | < Xires> | [[...]] to denote that section is not literally there |
| 03:03 | <&McMartin> | Mmm. |
| 03:03 | <&McMartin> | Yeah, I dunno |
| 03:09 | < Xires> | McMartin; np, ty again for all your guidance |
| 03:09 | <&McMartin> | you're welcome. Good luck. |
| 03:11 | | ktemkin is now known as ktemkin[awol] |
| 03:11 | < Azash> | McMartin, more than meets the eye |
| 03:11 | < Azash> | Stackoverflow in disguise |
| 03:12 | <&McMartin> | Greybeard |
| 03:13 | <&McMartin> | I should probably actually spend an hour or two a week trying to answer things on SO |
| 03:13 | < Azash> | Good practice if nothing else |
| 03:14 | < Xires> | http://pastie.org/private/li3ficeflrypacipywhwg |
| 03:14 | < Xires> | erm, sorry |
| 03:15 | <@Reiv> | McMartin: For purposes? |
| 03:16 | <&McMartin> | noblesse oblige mostly >_> |
| 03:16 | | * McMartin has been at this awhile now |
| 03:34 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds] |
| 03:34 | | Karono_ [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 03:37 | | Karono_ is now known as Karono |
| 03:40 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Client closed the connection] |
| 03:50 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code |
| 04:01 | | AnnoDomini [abudhabi@Nightstar-d410a3f0.adsl.inetia.pl] has quit [Ping timeout: 121 seconds] |
| 04:05 | < Xires> | McMartin; okay..so I thought you might be interested to know..after making just a few changes, particularly those to eliminate the strict-aliasing warnings, I have been waiting on the process to crash to see additional diagnostic information... |
| 04:05 | < Xires> | after lowering the timers to 1/20th of their original settings(which typically caused it to crash quit quickly)...it won't crash |
| 04:06 | < Xires> | I have it running on 4 VMs, twice on the host machine, on 3 remote VPS's, my work DevStack(6 times) + my laptop |
| 04:06 | < Xires> | not one of them has crashed |
| 04:07 | < Xires> | I'm afraid to say what I hope to be happening :-\ |
| 04:08 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Client closed the connection] |
| 04:08 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 04:15 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds] |
| 04:31 | <&McMartin> | Heh |
| 04:31 | <&McMartin> | Hope springs eternal~ |
| 04:31 | <&McMartin> | And there's a mechanism for what might be causing it, even! |
| 04:32 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 04:32 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 04:34 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:35 | | Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has quit [[NS] Quit: Bye] |
| 04:35 | | Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has joined #code |
| 04:35 | | Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has quit [Client closed the connection] |
| 05:04 | | Derakon is now known as Derakon[AFK] |
| 05:18 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 05:20 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 05:20 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code |
| 05:22 | | Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer] |
| 06:47 | | Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has joined #code |
| 08:02 | | ErikMesoy|sleep is now known as ErikMesoy |
| 08:20 | | Kindamoody is now known as Kindamoody|afk |
| 08:25 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has joined #code |
| 08:26 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 09:09 | | You're now known as TheWatcher |
| 09:11 | | AnnoDomini [abudhabi@Nightstar-d410a3f0.adsl.inetia.pl] has joined #code |
| 09:27 | | Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: Leaving] |
| 10:25 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 11:03 | <@TheWatcher> | So, I have a system that is used to create articles that appear in RSS/Atom feeds. It also needs to be able to send full copies of these articles to users via a number of other methods (including email and moodle forum posts). I have been calling this latter functionality "Notifications", but I have been told that this is confusing as a couple of people think this means that the system is sending "go look at this link" emails rather than "here is |
| 11:03 | <@TheWatcher> | the whole article" emails. Any suggestions for an alternative name for these things? |
| 11:05 | <@TheWatcher> | "Messaging" might work, I guess, but feels wrong. |
| 11:16 | <@Tamber> | "Memos"? |
| 11:21 | <@TheWatcher> | Maybe, although that comes with some associated assumptions for content that don't really apply. |
| 11:27 | < Syka> | "newsfeed"? |
| 11:30 | <@TheWatcher> | That's what the rss/atom feeds are for, not the direct emails or moodle posts |
| 11:31 | <@TheWatcher> | It needs to be something that translates as "I am sending you a full copy of this article direct to you" |
| 11:33 | <@Tamber> | "Journal"? ...eh, actually, I dunno; that might be interpreted more in the "diary" sense. |
| 11:33 | <@TheWatcher> | Yeah, guaranteed |
| 11:34 | <~Vornicus> | "newsletter" |
| 11:34 | <@TheWatcher> | Nameclash, the system already produces newsletters. |
| 11:35 | <~Vornicus> | failonaut |
| 11:36 | <@Tamber> | "Goddamn, you people are hard to please. Here's your damn articles"? |
| 11:36 | <@TheWatcher> | Very, very tempting. |
| 11:55 | < Syka> | "articool 9000" |
| 11:56 | < Syka> | TheWatcher: maybe just "Full Articles" or something |
| 12:05 | <@gnolam> | "CC"? |
| 12:14 | <@Alek> | Mimeo |
| 13:11 | | ktemkin[awol] is now known as ktemkin[work] |
| 13:25 | <&ToxicFrog> | Dispatches from the Front Lines |
| 13:27 | < Azash> | TheWatcher: "Delivery" ? |
| 13:34 | < Xires> | TheWatcher; I second Azash's suggestion..it seems most appropriate |
| 13:35 | <@TheWatcher> | I dunno, I kinda like ToxicFrog's. This is, after all, being used in a university >.> |
| 13:39 | < ErikMesoy> | "Readables"? |
| 13:39 | < ErikMesoy> | vaguely inspired by the "lunchables" snack |
| 13:40 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Client closed the connection] |
| 13:41 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 13:58 | < ktemkin[work]> | Subscriptions? |
| 14:02 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has joined #code |
| 14:02 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:02 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 14:03 | <@Alek> | not bad. |
| 14:04 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 14:04 | | celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has joined #code |
| 14:04 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:05 | <@TheWatcher> | Subscriptions doesn't work, as that implies that users have subscribed. Rather, these are being sent to groups of people determined using SECONDARY BLACK GRIMOIRE without intervention by the recipients |
| 14:07 | <@Alek> | Mandatory Subscriptions. |
| 14:08 | | * Alek repeats, |
| 14:08 | <@Alek> | Mimeos |
| 14:12 | <@gnolam> | Article CC. |
| 14:53 | < ktemkin[work]> | A subscription without explicit subscribers could be described as a "broadcast". |
| 14:53 | < ktemkin[work]> | Though that's picked up other connotations. |
| 14:57 | <&McMartin> | If you're getting it from SECONDARY BLACK GRIMOIRE, surely this is code NIGHTMARE GREEN. |
| 14:58 | <&McMartin> | Or NIGHTMARE GREEN code. Whatever. |
| 15:10 | < Xires> | TheWatcher; "HEY!"? inspired by the fairy from some Zelda game |
| 15:13 | <&McMartin> | HEY LISTEN |
| 15:14 | < Xires> | McMartin; ty again for your assistance yesterday |
| 15:14 | <&McMartin> | No worries. Has it actually helped? |
| 15:15 | < Syka> | xires: Navi? |
| 15:16 | < Xires> | Syka; ci |
| 15:17 | <@TheWatcher> | I'd rather not be beaten to death by co-workers. |
| 15:17 | <&McMartin> | Hee |
| 15:24 | < Xires> | ;-P |
| 15:36 | < ktemkin[work]> | And now I get to explain to our IT department's "unix expert" how to use the find command. |
| 15:36 | < ktemkin[work]> | Vunderbar. |
| 15:36 | <&McMartin> | ktemkin: So, do you use -exec grep or -print0 | xargs -0 grep |
| 15:37 | <&McMartin> | (The only argument even dumber than vi vs emacs) |
| 15:38 | < ktemkin[work]> | That's an argument? |
| 15:39 | <&McMartin> | Apparently people occasionally have strong preferences between the two! |
| 15:39 | < Azash> | http://www.kickstarter.com/projects/1523379957/oculus-rift-step-into-the-game/po sts/562211 |
| 15:40 | <&McMartin> | I don't even remember why. Something to do with the way xargs breaks up arguments into individual commands or doesn't |
| 15:43 | <&ToxicFrog> | If you're on a really old find, it doesn't support '-exec +', only '-exec ;', in which case xargs is the clearly superior choice |
| 15:43 | <&ToxicFrog> | Otherwise, -exec + is functionally equivalent to | xargs and may actually use the same code. |
| 15:46 | <&McMartin> | I actually didn't know about -exec +~ |
| 15:48 | < ktemkin[work]> | Googling seems to show that there are advantages to both methods. |
| 15:50 | < ktemkin[work]> | While -exec + is typically faster (only one find process to run your commands, instead of find/xargs) and can be chained (you can add additional find options after it), xarg will let you spawn multiple processes with the "-P" flag, so you can run your individual execs in parallel, if the task permits. |
| 15:50 | < ktemkin[work]> | *xargs |
| 15:51 | < ktemkin[work]> | I suppose you could do that by backgrounding your find calls; but you wouldn't have control over how many processes were running. |
| 15:51 | < ktemkin[work]> | "calls" being for lack of a better word. >.> |
| 15:58 | <@gnolam> | Azash: cool |
| 16:17 | | Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has quit [Client closed the connection] |
| 17:19 | < Xires> | I thought awk vs sed was the dumbest argument |
| 17:23 | < Syka> | no, that's probably awk vs gawk |
| 17:31 | <&ToxicFrog> | PHP vs anything else is the dumbest argument~ |
| 17:33 | < Syka> | it's also the simplest argument |
| 17:33 | < Syka> | "PHP is great!" "No it's not, shut up, before I set you on fire" |
| 17:35 | < ErikMesoy> | *before I hit you with this double-clawed hammer |
| 17:35 | < Syka> | PHP being a double clawed hammer doesn't make sense to me |
| 17:36 | < Syka> | I mean, a hammer has a solid handle |
| 17:36 | < Syka> | PHP's handle is like one of those pool noodles |
| 17:37 | <@Tamber> | It makes sense in that "You can still actually *use* it to build proper stuff; but it's a lot harder than if you used a decent tool" |
| 18:13 | < ktemkin[work]> | And if you assume it works in an at-all standard way, you'll hurt whatever you point it at. ^-^ |
| 18:49 | <&McMartin> | ... huh, SDL has a package update on Fedora. |
| 19:05 | <@gnolam> | 1.x or 2? |
| 19:10 | <&McMartin> | 1.x |
| 19:13 | <@gnolam> | Strange. I'm not seing anything more recent than 1.2.15 on the SDL web page. |
| 19:14 | <&McMartin> | Yeah, this was an update to the 1.2.15 package |
| 19:22 | < Syka> | oh my god |
| 19:22 | < Syka> | i have spent like... 30 mins to 45 mins on the phone with microsoft |
| 19:22 | < Syka> | attempting to get this license activated |
| 19:22 | < Syka> | i had to give my name and email (which is fairly complex to spell out) TWICE |
| 19:22 | < Syka> | i had to type/speak out the 54 number id FOUR TIMES |
| 19:23 | < Syka> | and got transferred THREE TIMES |
| 19:23 | < Syka> | the last two people were seemingly unaable to comprehend "019" |
| 19:23 | < Syka> | and typed it down as "0891" |
| 19:24 | < Syka> | god why is dealing with microsoft licensing such a shitshow |
| 19:26 | < Azash> | Syka: http://www.codinghorror.com/.a/6a0120a85dcdae970b017742d249d5970d-800wi |
| 19:29 | < Azash> | And speaking of PHP |
| 19:29 | < Azash> | http://www.reddit.com/r/netsec/comments/1ju6zh/php_exif_backdoors_generator_usin g_custom/ |
| 19:30 | < Azash> | "However, preg_replace has a hidden and tricky option where if you pass the â/eâ modifier it will execute the content (eval), instead of just searching/replacing." |
| 19:31 | <@gnolam> | "hidden at the top of the php man page for preg_replace" |
| 19:41 | <@Namegduf> | XD |
| 19:47 | <&ToxicFrog> | Considering what the PHP docs are often like, that may qualify as "hidden"~ |
| 20:06 | | * McMartin crosses a spider with the King of the Koopas. |
| 20:06 | | * McMartin has crafted a Web Bowser. |
| 20:06 | <@TheWatcher> | ... |
| 20:30 | < Xires> | can someone please load http://www.geany.org/ & tell me what the latest version is? DNS issues are preventing the site from loading on my end |
| 20:31 | <@TheWatcher> | 1.23.1 |
| 20:31 | < Xires> | tyvm, TheWatcher |
| 21:40 | | Kindamoody|afk is now known as Kindamoody |
| 21:45 | | Kindamoody is now known as Kindamoody[zZz] |
| 22:08 | | ToxicFrog_ [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 22:09 | | ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has quit [Operation timed out] |
| 22:41 | | ErikMesoy is now known as ErikMesoy|sleep |
| 22:51 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| --- Log closed Thu Aug 08 00:00:03 2013 |