ushakovo 2017-02-27 20:46:34
Are beginner type questions allowed here?
liste 2017-02-27 20:46:41
ushakovo: yes
cocreature 2017-02-27 20:46:47
absolutely!
ushakovo 2017-02-27 20:47:39
awesome! I am working on a project and I am receiving the error message "Segmentation fault/access violation in generated code"
ushakovo 2017-02-27 20:47:57
I think haskell is a pretty "safe" language so I was surprised to receive that message
Cale 2017-02-27 20:48:01
Does your project do FFI?
ushakovo 2017-02-27 20:48:17
everything I have found has been users reporting various ghc errors
ushakovo 2017-02-27 20:48:45
yes it does
Cale 2017-02-27 20:48:52
That's either a GHC bug, or something is using a low level pointer operation (usually for the purposes of interacting with a C library)
Cale 2017-02-27 20:49:14
or the C library itself is causing the segfault
ushakovo 2017-02-27 20:49:32
I see. Unfortunately the code that would be calling a C pointer is in a library I am using
Cale 2017-02-27 20:49:56
What seems to be causing it?
Cale 2017-02-27 20:50:08
Ptival: Interesting approach :)
cocreature 2017-02-27 20:50:37
Ptival: I need to read it more closely later but it looks pretty cool!
cocreature 2017-02-27 20:51:04
now someone only needs to come up with a way to remove the need to left factor your parser combinators and I'm happy
ushakovo 2017-02-27 20:51:19
I am using a library to play music. The library uses the Rational type to represent note durations
cocreature 2017-02-27 20:51:35
ushakovo: I think your best bet is to try to isolate the code that is causing the error
ushakovo 2017-02-27 20:53:23
cocreature: I think I've isolated it but I'm not sure how to fix it. I'll keep working at it though
ushakovo 2017-02-27 20:53:44
I was more curious what the error message meant, so thanks for the help!
liste 2017-02-27 20:54:41
ushakovo: segmentation fault means that some C/FFI code is trying to access memory not allocated the program
ongy 2017-02-27 20:54:55
or someone used unsafe where it wasn't safe
ushakovo 2017-02-27 20:55:57
I think the error may not lie in my code then
ushakovo 2017-02-27 20:56:30
or I need to use the code given in a different way
ongy 2017-02-27 20:56:48
probably not. The library *may* be exposing something that can be prevented by the user. But I think that's bad design from the library (to then segfault)
ushakovo 2017-02-27 20:59:58
Well that's unlucky
ushakovo 2017-02-27 21:00:11
I'm gonna need a new project to work on then haha
cocreature 2017-02-27 21:01:52
ushakovo: you can always post your code here and hope that someone finds the time to look at it :)
ushakovo 2017-02-27 21:04:09
cocreature: I'd rather not subject anyone to my newbie haskell...
ushakovo 2017-02-27 21:04:37
I contacted the creator of the library so maybe they'll be interested in it
cocreature 2017-02-27 21:04:52
ushakovo: don't worry about that. people that hang around here usually do because they want to help others
cocreature 2017-02-27 21:04:59
we've all been beginners at some point
fuzzy_id 2017-02-27 21:07:37
heya
ushakovo 2017-02-27 21:08:25
cocreature: the help has been great! I'm 90% sure the problem isn't with my code, but if I get really desperate I'll be back
cocreature 2017-02-27 21:08:48
ushakovo: alright, I hope you'll be able to fix the bug!
fuzzy_id 2017-02-27 21:09:04
I spawn an external process via createProcess and try to read the resulting stderr and stdout handles in forkIO'd threads (passing lines back in MVars to feed them back to my logging stack).
fuzzy_id 2017-02-27 21:09:23
now my program uses 100% cpu while the other program is running :/
fuzzy_id 2017-02-27 21:09:51
can someone point me in the right direction how to avoid that?
ushakovo 2017-02-27 21:10:16
cocreature: Thanks!
fuzzy_id 2017-02-27 21:10:18
is there some routine that uses select in the background?
Cale 2017-02-27 21:10:21
fuzzy_id: it's unclear to me from that description why your program would do that
cocreature 2017-02-27 21:10:45
fuzzy_id: ghc generally uses "select" by default. could you show us the code you're using to read the output?
Cale 2017-02-27 21:10:49
Yeah, just ordinary IO will use select/epoll/kqueue as appropriate based on your platform
ongy 2017-02-27 21:10:50
fuzzy_id: I don't think that should happen. And there's the RTS in the background managing IO
fuzzy_id 2017-02-27 21:11:11
just one moment
cocreature 2017-02-27 21:11:12
also maybe try the threaded runtime. weird things happen sometimes using the nonthreaded runtime
Cale 2017-02-27 21:11:17
ah yeah
cocreature 2017-02-27 21:11:42
we really should just make the threaded runtime the default.
Cale 2017-02-27 21:11:49
We should
ongy 2017-02-27 21:11:50
iirc non-threaded runtime uses the normal epoll manager and additional selects around reads
cocreature 2017-02-27 21:11:54
it comes up from time to time and everybody seems to agree but for some reason it doesn't happen
fuzzy_id 2017-02-27 21:12:57
https://github.com/fuzzy-id/btrbkp/blob/master/src/Btrbkp/BkpStore/Local.hs
fuzzy_id 2017-02-27 21:13:14
logProcess is the calling function (line 71…)
cocreature 2017-02-27 21:13:46
fuzzy_id: do you use the threaded runtime? if not try that first
fuzzy_id 2017-02-27 21:13:54
alright
cocreature 2017-02-27 21:15:16
the mvar could also become a bottleneck if there is a lot of output on both stdout & stderr
fuzzy_id 2017-02-27 21:23:29
is there some way to see if '-threaded' was actually set during compilation?
fuzzy_id 2017-02-27 21:23:47
i'm not sure when stack actually rebuilds… :)
fuzzy_id 2017-02-27 21:23:56
i set ghc-options in the cabal file…
cocreature 2017-02-27 21:24:13
try running your executable with +RTS --info
cocreature 2017-02-27 21:24:24
I think "RTS way" shows you what it used
fuzzy_id 2017-02-27 21:25:21
"RTS way" is set tho "rts_thr"
cocreature 2017-02-27 21:25:27
that looks fine
cocreature 2017-02-27 21:26:05
fuzzy_id: oh I think I found the problem
cocreature 2017-02-27 21:26:10
fuzzy_id: you are using "tryTakeMVar"
cocreature 2017-02-27 21:26:18
so you are essentially doing a busy loop
cocreature 2017-02-27 21:26:22
even if there is no output
cocreature 2017-02-27 21:26:30
oh no you exit in that case nvm
cocreature 2017-02-27 21:26:51
no it's a busy loop
fuzzy_id 2017-02-27 21:26:54
nope, i don't
fuzzy_id 2017-02-27 21:27:00
yeah, you're right
cocreature 2017-02-27 21:29:50
one way to fix this is to use a bounded channel instead of an mvar and have it hold "Maybe Text", then errThread and outThread both write Nothing if they are finished and loopLogProcess steps looping once it encountered two Nothings
fuzzy_id 2017-02-27 21:32:32
where can i find bounded channels
cocreature 2017-02-27 21:34:14
https://hackage.haskell.org/package/unagi-chan-0.4.0.0/docs/Control-Concurrent-Chan-Unagi-Bounded.html is one of the faster implementations afaik
cocreature 2017-02-27 21:34:37
https://hackage.haskell.org/package/unagi-chan-0.4.0.0/docs/Control-Concurrent-Chan-Unagi-Bounded.html is one of the faster implementations afaik
mniip 2017-02-27 21:35:45
https://hackage.haskell.org/package/unagi-chan-0.4.0.0/docs/Control-Concurrent-Chan-Unagi-Bounded.html is one of the faster implementations afaik
fuzzy_id 2017-02-27 21:38:23
the bound simply ensures that my reading thread will read although my program writes a lot to stdout/stderr, right?
cocreature 2017-02-27 21:39:06
the bound ensures that your writing thread will block if the reading thread doesn't keep up
cocreature 2017-02-27 21:39:16
you can think of your current approach using an mvar as a bounded channel of size 1
cocreature 2017-02-27 21:39:51
you could also use an unbounded channel but unbounded channels are usually a bad idea :)
fuzzy_id 2017-02-27 21:40:35
yeah, that makes sense
fuzzy_id 2017-02-27 21:40:39
:)
