ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
aw- has joined #picolisp
dexen has quit [Ping timeout: 260 seconds]
<aw-> Regenaxer: good morning, with (native) I have a result specification which looks like this: (list 'Attr (64 N . 4) 0)
<Regenaxer> Hi aw-!
<aw-> a 64-byte buffer which only returns a list of 4 x 8-byte longs
<aw-> i want to know: is that "dangerous" ?
<Regenaxer> and only the first byte is initalized
<aw-> oh right, missing the . 0
<Regenaxer> ok
<aw-> (list 'Attr (64 N . 4) . 0)
<Regenaxer> I think it is not dangerous
<Regenaxer> just the buffer is too big
<Regenaxer> no problem
<aw-> the function needs a 64-byte buffer
<aw-> but i only need the first 32 bytes
<Regenaxer> ah, ok
<Regenaxer> good
<Regenaxer> Why should it be dangerous?
<aw-> accepting more data than I need?
<Regenaxer> The C function does not care what Lisp does with the buffer
<Regenaxer> You could ignore it all
<Regenaxer> 'native' allocates 64 bytes, passes the pointer to C, reads 4 longs, and discards the buffer
<aw-> i see
<aw-> you dont worry about buffer overflow when using malloc with (native) ?
<Regenaxer> overflow is a matter of the C function
<Regenaxer> It must behave well
<aw-> right
<aw-> if i can't see the code for the C function? should i write my picolisp to protect from that situation?
<Regenaxer> I think there is no way, except for allocating an even bigger buffer
<Regenaxer> Do you suspect that the function is bad?
<aw-> no
<aw-> but i don't know
<aw-> i gotta go, back in a bit
<aw-> thanks
<Regenaxer> ok :)
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
rob_w has joined #picolisp
mtsd has joined #picolisp
<tankf33der> ersatz works in java15.
<Regenaxer> Thanks!
<Regenaxer> I continue with GUI for pil21 now
<Regenaxer> The base system seems to work so far
<Regenaxer> At least I have no known issues at the moment
<Regenaxer> Most critical is DB
<Regenaxer> Most of the bugs of the last days were DB and OOP
<Regenaxer> and there are surely more
orivej has joined #picolisp
dexen has joined #picolisp
<tankf33der> pil21 can work under address+undefined sanitizers.
<tankf33der> fails on memory one, its ok.
<Regenaxer> Do you know the reason?
<tankf33der> http://ix.io/2yzV
<tankf33der> in general should be easy.
<Regenaxer> What kind of write does it mean? write(2) ?
<Regenaxer> or memory?
<Regenaxer> What uninitialized value is it?
<tankf33der> # make
<tankf33der> ==1766==WARNING: MemorySanitizer: use-of-uninitialized-value
<tankf33der> #0 0x4c014d in wrBytes (/root/pil21/bin/picolisp+0x4c014d)
<tankf33der> ../pil lib/llvm.l main.l -bye > base.ll
<tankf33der> Uninitialized bytes in __interceptor_write at offset 0 inside [0x72100000140c, 4096)
<tankf33der> #2 0x4c9d42 in prName (/root/pil21/bin/picolisp+0x4c9d42)
<tankf33der> #1 0x4be0b8 in _putStdout (/root/pil21/bin/picolisp+0x4be0b8)
<tankf33der> cant find yet.
<Regenaxer> Perhaps this is a real bug
<Regenaxer> would be interesting to understand what that means
<tankf33der> # ./picolisp-msan /root/t1.l -bye > dfdd
<tankf33der> ==2237==WARNING: MemorySanitizer: use-of-uninitialized-value
<tankf33der> #0 0x4c014d in wrBytes /root/pil21/src/picolisp.s:49066
<tankf33der> Uninitialized bytes in __interceptor_write at offset 0 inside [0x72100000140c, 159)
<tankf33der> #1 0x4c00c5 in flush /root/pil21/src/picolisp.s:48990
<tankf33der> #3 0x4be334 in bye /root/pil21/src/picolisp.s:45901
<tankf33der> #2 0x4be368 in flushAll /root/pil21/src/picolisp.s:45934
<tankf33der> now got line numbers in picolisp.s file.
<Regenaxer> ok
<Regenaxer> Your line numbers are different from mine probably
<Regenaxer> Can you pastebin your picolisp.s file?
<tankf33der> doing.
<tankf33der> too big for ix.io
<Regenaxer> oh!
<Regenaxer> only flush then
<tankf33der> try to download from this url then.
<tankf33der> full file.
<Regenaxer> good
<tankf33der> this file is without opt -O3
<tankf33der> flat, as is.
<Regenaxer> No lines added, so that linenumber matches?
<Regenaxer> 45901
<Regenaxer> hmm
<Regenaxer> ImovqI%rbx, %rsi
<Regenaxer> movqI%rbx, %rsi
<Regenaxer> is not a memory access
<Regenaxer> and not a write
<Regenaxer> also, not in flush() but in _ge
<Regenaxer> Something is very wrong
<Regenaxer> ah, wait
<Regenaxer> I looked wrong
<Regenaxer> 49066
<Regenaxer> hmm, neither
<Regenaxer> it is in prove
<Regenaxer> I give up
<tankf33der> eh, as is.
<Regenaxer> wrBytes() looks correct
<Regenaxer> called by flush()
<Regenaxer> The line number above make no sense
<Regenaxer> but I know that write is called in wrBytes
<Regenaxer> : (vi 'wrBytes)
<Regenaxer> Perhaps some buffer indexes are wrong
<Regenaxer> I insert some debug code
<Regenaxer> How did you call it?
<Regenaxer> i.e. can I reproduce?
<aw-> back
<Regenaxer> hi :)
<aw-> hi
<Regenaxer> tankf33der: *Where* does it write to? If really uninitialized, the written data should be nonsense
<Regenaxer> stdout?
<Regenaxer> or a file?
beneroth has joined #picolisp
<tankf33der> afk.
<tankf33der> cant right now.
<Regenaxer> ok
<Regenaxer> no hurry
<tankf33der> 12:06 <tankf33der> # ./picolisp-msan /root/t1.l -bye > dfdd
<tankf33der> as you can see i just called a file this way
<tankf33der> and t1.l file is just:
<tankf33der> println apply * range 1 100
<tankf33der> .
<tankf33der> just one line
<Regenaxer> is garbage in the file?
<Regenaxer> Could you strace and send me?
<Regenaxer> I can look at write() calls
<tankf33der> in dfdd correct number
<tankf33der> http://ix.io/2yAl
<tankf33der> ^^^ this is strace of:
<tankf33der> strace ./picolisp-msan /root/t1.l -bye > dfdd
<Regenaxer> checking ...
<Regenaxer> does it write numbers like "93326215443944152681699238856266"?
<tankf33der> yeap
<Regenaxer> after that only write(2, "\33[1m\33[31mUninitialized bytes
<Regenaxer> So write seems ok
<tankf33der> : (apply * (range 1 100))
<tankf33der> -> 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
<tankf33der> :
<Regenaxer> yeah
<tankf33der> maybe printing second cons of bignum is wrong somehow.
<Regenaxer> length of that num is 158
<Regenaxer> write(1, "93326215443944152681699238856266"..., 159) = 159
<Regenaxer> so a space or newline?
<Regenaxer> How does it find out uninitialized memory? By pre-filling with some pattern?
<Regenaxer> No idea why it complains
<tankf33der> sanitizer counts memory access.
<tankf33der> if checked then ok.
<Regenaxer> checked in which way?
orivej has quit [Ping timeout: 256 seconds]
<beneroth> hi Regenaxer, tankf33der
<beneroth> Regenaxer, for every memory read, check if it was written before, if not == uninitialized memory access
<beneroth> if that is the topic...
<Regenaxer> Hi beneroth
<Regenaxer> it checks by pre-filling?
<Regenaxer> Or how else?
<beneroth> I don't know the method here in question
<Regenaxer> It cannot track every memory access without hardware support
<beneroth> but prefilling, or with active profiling like pil's (trace), decorate every memory access call
<Regenaxer> and obviously the memory is correct here
<Regenaxer> the contents
<beneroth> can't it, if its goes basically MitM between the software and the hardware?
<beneroth> hm ok
<Regenaxer> to trace it that way, it must track machine instructions
<Regenaxer> ie hardware
<Regenaxer> perhaps CPUs support that
<Regenaxer> debug instructions
<Regenaxer> probably only by super user
<Regenaxer> anyway
<Regenaxer> I'd like to know why it believes it is uninitialized. Perhaps it is. But which memory?
<Regenaxer> Not very helpful
<beneroth> yeah which memory is the question
<Regenaxer> If it really detects it, it should better tell exactly *which* range of memory
<Regenaxer> T
<Regenaxer> Above we write() 159 byte
<Regenaxer> the number has 158
<Regenaxer> I assume the last byte is a newline
<Regenaxer> So everything looks good
rob_w has quit [Ping timeout: 272 seconds]
rob_w has joined #picolisp
mtsd has quit [Quit: Leaving]
orivej has joined #picolisp
rob_w has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
<dexen> perhaps could use the paging mechanism for tracking all memory accesses?
<dexen> rough idea: allocate a protected (no read, no write) memory region. adjust all *relevant* pointers by adding a large constant, to make them all point to the protected memory region.
<dexen> any attempt at accessing the pointer will cause SIGSEGV, catch it, subtract the large constant from the pointer to obtain the *actual* / original value
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Excess Flood]
orivej has joined #picolisp