@Magisch that's sorta the conclusion I was coming to. I'm assuming you don't need to freenew_origin and new_raw because *into stores a pointer to them and accessing a free'd pointer sounds bad?
@QPaysTaxes Is it, though? I don't know enough about C, here, but it looks to me like tst_restore_state calls tst_push for any previously-popped tokens. tst_push takes a pointer to the stack, and a non-pointer parameter for the copied token. tst_restore_state provides the stack pointer, and todo.data.popped. In turn, todo.data.popped is supplied from tst_pop when it was stored.
token_stack.c:101 is not a pointer. So, on token_stack.c:106, are you assigning the same block of memory that copy is stored in, or are you assigning a copy of copy?
@ArtOfCode @Undo @angussidney the core problem here is that answer handling isn't clearly getting the "title" from anywhere, and it's checking titles somewhere in the handler. I'll have to mess with check if spam then
@quartata We need to try and stop passing between fifty objects. I have to revise the test_post to properly check if we're an answer before doing any title reason appends
@YvetteColomb Well, my apartment is where the souls of the condemned gather, ultimately consumed and destroyed by my massive systems infrastructure that extracts power from the souls...
@QPaysTaxes IIRC it won't give you every memory access; just things like mallocs and frees. It's designed for detecting invalid memory accesses; not memory leaks.
Xcode's Instruments has a leak checker -I'll see if I can get anything useful out of that later this afternoon.
@Henders not when Undo purges from the database - here's a tip if it has no site corresponding to it, it says "posted by <nothing>", and the "View on site" link points to no-where, assume it's junk data.
at least, if it has that string that is
because i'm using old posts that were already triggered as test data
and sometimes it submits to MS before my debugger catches the breakpoint. Last several runs I've been stopping it befoire it launches the MS report thread, so meh
that should be the last time I put crap data in MS, if all goes well heh
@ArtOfCode i think I've fixed the MS report part with answers not passing a title - in this case, i've got an if statement before the thread that determines whether to pass parent title (if it's an answer) or to pass the title for the post itself (if it's not an answer). This isn't the best process but...
@Henders not when Undo purges from the database - here's a tip if it has no site corresponding to it, it says "posted by <nothing>", and the "View on site" link points to no-where, assume it's junk data.
@quartata well, it's "me" in the sense the report was issued from Overlord's MS key
but it's not me because it's a post written from scratch without actual data from SE API
(the same way we create 'false' posts in the unit tests, works for testing the functionality outside of a Smokey run too, and is how I discovered all the errors in the answer processing that were being absorbed by the try/except:pass stuff)
@quartata but now that answers are properly being handled by Smokey now, we only need to make sure MS gets the right data, which it wasn't on this one
thanks, @Undo. The system should now work with answers and not throw title alerts. AND it should be passing the parent post title to MetaSmoke instead of passing an empty string.
