Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 .. 5022
— 502,152 events total
2020-11-02 19:27:59 → Amras joins (~Amras@unaffiliated/amras0000)
2020-11-02 19:28:45 → christo joins (~chris@81.96.113.213)
2020-11-02 19:30:53 × u0_a298 quits (~user@47.206.148.226) (Read error: Connection reset by peer)
2020-11-02 19:31:09 → u0_a298 joins (~user@47.206.148.226)
2020-11-02 19:32:25 → Deide joins (~Deide@217.155.19.23)
2020-11-02 19:33:05 × dcoutts_ quits (~duncan@33.14.75.194.dyn.plus.net) (Ping timeout: 240 seconds)
2020-11-02 19:33:15 → refried_ joins (~textual@pool-108-20-26-90.bstnma.fios.verizon.net)
2020-11-02 19:33:21 × bliminse quits (~bliminse@host109-156-197-211.range109-156.btcentralplus.com) (Ping timeout: 256 seconds)
2020-11-02 19:33:55 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 19:33:58 × refried_ quits (~textual@pool-108-20-26-90.bstnma.fios.verizon.net) (Client Quit)
2020-11-02 19:34:04 → bliminse joins (~bliminse@host109-156-197-211.range109-156.btcentralplus.com)
2020-11-02 19:34:27 → geekosaur joins (82659a09@host154-009.vpn.uakron.edu)
2020-11-02 19:35:02 → dcoutts_ joins (~duncan@33.14.75.194.dyn.plus.net)
2020-11-02 19:36:32 <bqv> Friends how would you debug ffi-heavy haskell?
2020-11-02 19:37:04 <maerwald> debug what
2020-11-02 19:37:35 <bqv> Well see I have an issue. My program exits
2020-11-02 19:37:45 <bqv> But not in failure, just exits
2020-11-02 19:37:56 <bqv> No clue why, need to get interactive
2020-11-02 19:38:01 × raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Read error: Connection reset by peer)
2020-11-02 19:38:05 <bqv> But I reckon its in the C code
2020-11-02 19:38:30 <sm[m]> reckon yer right, pardner
2020-11-02 19:38:31 → raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2020-11-02 19:38:37 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 264 seconds)
2020-11-02 19:38:41 <geekosaur> since FFI is typically in IO, I do a lot of logging around the FFI calls. that said, if something in C is calling exit(), you can't typically intervene and it won't return control to Haskell
2020-11-02 19:39:10 <geekosaur> the best you might do is an atexit handler that prints something while it's on the way out
2020-11-02 19:39:15 × Saukk quits (~Saukk@2001:998:f9:2914:1c59:9bb5:b94c:4) (Remote host closed the connection)
2020-11-02 19:39:16 <bqv> I've narrowed it down to the call, but now I wanna peek into that call
2020-11-02 19:39:31 <bqv> But... gdb? Haskell?
2020-11-02 19:39:42 <bqv> Is that even realistic?
2020-11-02 19:39:43 → AlterEgo- joins (~ladew@124-198-158-163.dynamic.caiway.nl)
2020-11-02 19:39:49 <monochrom> Can you add fprint(stderr's to the C code?
2020-11-02 19:39:55 <geekosaur> you'd be able to trace back to the start of the call, at least
2020-11-02 19:39:58 <bqv> The c code isn't mine :D
2020-11-02 19:40:04 <bqv> Its a library
2020-11-02 19:40:22 <bqv> Eh, I suppose I could recompile it
2020-11-02 19:40:28 <sm[m]> yes, people successfully use gdb for this kind of thing I believe
2020-11-02 19:40:36 <bqv> Thats a nuclear option though
2020-11-02 19:40:59 <bqv> sm[m]: is there a trick to it or will it work ootb?
2020-11-02 19:41:34 <pjb> nowadays we have the sources almost all the time, so you can just edit and recompile the library to help debug.
2020-11-02 19:41:35 <sm[m]> I don't know gdb unfortunately.. someone here will know, otherwise try #ghc
2020-11-02 19:41:57 <pjb> Sometimes there are already various DEBUG defines you can set to add traces.
2020-11-02 19:42:08 <sm[m]> sometimes it's easier to read code and think about what could be going wrong
2020-11-02 19:42:15 × ubert quits (~Thunderbi@p200300ecdf1e530be6b318fffe838f33.dip0.t-ipconnect.de) (Remote host closed the connection)
2020-11-02 19:42:35 <pjb> Depends on the kind of bug.
2020-11-02 19:42:45 × knupfer quits (~Thunderbi@200116b82c45b300e014d1b214daaf45.dip.versatel-1u1.de) (Quit: knupfer)
2020-11-02 19:42:57 → knupfer joins (~Thunderbi@200116b82c45b3000805a93423d8669d.dip.versatel-1u1.de)
2020-11-02 19:42:57 × raichoo quits (~raichoo@dslb-092-073-210-010.092.073.pools.vodafone-ip.de) (Quit: Lost terminal)
2020-11-02 19:42:59 × invaser quits (~Thunderbi@31.148.23.125) (Ping timeout: 256 seconds)
2020-11-02 19:43:10 → solonarv joins (~solonarv@astrasbourg-653-1-117-122.w90-33.abo.wanadoo.fr)
2020-11-02 19:43:14 <bqv> Ack, there's another complication
2020-11-02 19:43:19 <pjb> But one problem with reading the code (when it's you who wrote it), is that if there's a bug, it's because you have bad expectation about what it does, so reading again only makes you think about the bad interpretation, not the actual real one.
2020-11-02 19:43:32 <pjb> Hence running it with prints. Here the problems usually jump to the eyes.
2020-11-02 19:43:50 <bqv> The program has to be executed by another certain launcher...
2020-11-02 19:44:01 <bqv> That makes gdb a pain
2020-11-02 19:44:35 <pjb> You can wrap your program in a shell script, to log the arguments and environment set up by the launcher. Then you can replicate them in gdb.
2020-11-02 19:45:03 <bqv> Its IPC
2020-11-02 19:45:06 → kritzefitz joins (~kritzefit@212.86.56.80)
2020-11-02 19:45:09 <bqv> And setuid
2020-11-02 19:45:12 <bqv> Not environment
2020-11-02 19:45:26 <pjb> gdb can also attach to a process that's already run, eg. if your launcher sets up pipes and communicate with your program.
2020-11-02 19:45:34 <pjb> gdb attach command is great!
2020-11-02 19:46:00 <bqv> yeah, that would be the plan, so it would just be a matter of getting it to break immediately on launch so I can catch it
2020-11-02 19:46:09 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 19:46:37 <tomsmeding> can't you just put 'threadDelay 1000000' at the start of your haskell program
2020-11-02 19:46:45 <tomsmeding> or well, perhaps add a zero
2020-11-02 19:46:47 → mbomba joins (~mbomba@bras-base-toroon2719w-grc-49-142-114-9-241.dsl.bell.ca)
2020-11-02 19:46:57 <bqv> Ahah, true
2020-11-02 19:48:39 <tomsmeding> also if you want to postpone gdb for some reason (perhaps the library doesn't have debug symbols?), you can also run your program under 'strace -f -o log.txt'
2020-11-02 19:48:49 <tomsmeding> and then grep the produced log.txt for the process ID if your program
2020-11-02 19:49:11 <tomsmeding> (also -ff may be useful instead of -f, see the strace man page)
2020-11-02 19:49:19 × mokulus_ quits (~mat@176.111.230.96) (Quit: WeeChat 2.9)
2020-11-02 19:49:33 <tomsmeding> also maybe ltrace? though that's a bit hit and miss sometimes
2020-11-02 19:49:37 → mokulus joins (~mat@176.111.230.96)
2020-11-02 19:49:49 <bqv> Oh that's a good point, yeah ltrace sounds an extremely easy win if it works
2020-11-02 19:51:02 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 264 seconds)
2020-11-02 19:53:31 × aarvar quits (~foewfoiew@50.35.43.33) (Quit: Leaving.)
2020-11-02 19:53:34 × juuandyy quits (~juuandyy@90.166.144.65) (Quit: Konversation terminated!)
2020-11-02 19:54:24 <bqv> You're kidding. Adding ltrace made the bug vanish
2020-11-02 19:54:52 <maerwald> lolo
2020-11-02 19:55:07 <maerwald> the beauty of debugging
2020-11-02 19:55:36 <bqv> Extraordinary and inconvenient
2020-11-02 19:55:46 <tomsmeding> does the library you call spawn new processes/threads?
2020-11-02 19:55:56 <maerwald> space leak gone as soon as you enable heap profiling :p
2020-11-02 19:56:10 <sm[m]> how about strace
2020-11-02 19:56:17 <bqv> No processes, but threads yes
2020-11-02 19:56:29 <tomsmeding> I bet something in your system receives a signal, and thus quits, and there is a wrapper around that that swallows the non-zero exit code
2020-11-02 19:56:45 <tomsmeding> where "system" is collection of processes that your launcher starts
2020-11-02 19:57:18 <bqv> ha! Strace works too...
2020-11-02 19:58:01 <tomsmeding> "works" as in prevents the exit?
2020-11-02 19:58:05 <bqv> Yes
2020-11-02 19:58:10 <tomsmeding> fascinating
2020-11-02 19:58:13 <tomsmeding> try gdb and valgrind
2020-11-02 19:58:22 → ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-02 19:58:38 <bqv> those are far more complicated, i don't think i can try them right now
2020-11-02 19:58:54 <tomsmeding> "can" as in want to, or understand how to?
2020-11-02 19:59:10 <sm[m]> presumably it's not being killed by the OOM killer
2020-11-02 19:59:14 <bqv> it's just problematic because this is a display compositor, so it being STOPped means my pc is unusable
2020-11-02 19:59:21 <bqv> i need a second machine to gdb it
2020-11-02 19:59:25 <bqv> as i discovered a few minutes ago
2020-11-02 19:59:25 <tomsmeding> oof
←Prev  Next→
Page 1 .. 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 .. 5022

All times are in UTC.