Mirror of forum.nim-lang.org

1050 :: SIGSEGV: Illegal storage access when using net.readLine

• didlybom (orginal) [2015-03-19T16:47:30+01:00] view original

  Hi,

  I wrote some test code to learn how to use the net module:

  import net
  
  var sock = newSocket()
  
  sock.connect("myserver", port=net.Port(23))
  
  var data: string
  sock.readLine(data)
  echo(data)
  Run

  This compiles fine (on a Windows machine, using the compiler that comes witht he Windows nim installer):

  E:\Nim-devel\play>nim c --threads:on -d:useSysAssert -d:useGcAssert connect.nim
  Hint: used config file 'E:\Nim\config\nim.cfg' [Conf]
  Hint: system [Processing]
  Hint: connect [Processing]
  Hint: net [Processing]
  Hint: rawsockets [Processing]
  Hint: unsigned [Processing]
  Hint: os [Processing]
  Hint: strutils [Processing]
  Hint: parseutils [Processing]
  Hint: times [Processing]
  Hint: winlean [Processing]
  connect.nim(5, 0) Warning: not GC-safe: 'sock' [GcUnsafe]
  connect.nim(8, 0) Warning: not GC-safe: 'sock' [GcUnsafe]
  connect.nim(8, 14) Warning: not GC-safe: 'data' [GcUnsafe]
  CC: compiler_connect
  [Linking]
  Hint: operation successful (17103 lines compiled; 0.983 sec total; 18.184MB) [SuccessX]
  Run

  However, when I run it I get a crash with the following error message:

  E:\Nim-devel\play>connect
  Traceback (most recent call last)
  connect.nim(8)           connect
  net.nim(752)             readLine
  SIGSEGV: Illegal storage access. (Try to compile with -d:useSysAssert -d:useGcAssert for details.)
  Run

  As you can see I already added the suggested compiler switches but I get the same error and the same information.

  What am I doing wrong?

---

• singularity (orginal) [2015-03-19T17:44:53+01:00] view original

  You need to initialize data before using it.

  
  import net
  
  var sock = newSocket()
  
  sock.connect("myserver", port=net.Port(23))
  
  var data = ""
  sock.readLine(data)
  echo(data)
  Run

---

• Stefan_Salewski (orginal) [2015-03-19T18:03:22+01:00] view original

  You need to initialize data before using it.

  Not really easy to remember that. :-(

---

• OderWat (orginal) [2015-03-19T18:14:56+01:00] view original

  I wonder if missing the string initialisation could be a lint?

---

• Varriount (orginal) [2015-03-19T21:19:45+01:00] view original

  OderWat: The problem with this is that an uninitialized string isn't always a problem. What if I pass an uninitialized string to a procedure which takes a different code-path depending on whether the passed string is initialized or not? We do have 'not nil' annotations - it would probably make sense to just annotate stdlib code with that (and give users some way to override the annotation)

---

• didlybom (orginal) [2015-03-19T22:06:43+01:00] view original

  I think this error is very easy to make! I'm a bit surprised that it is so easy to get such a crash with nim, particularly when using nim's standard library. The documentation does not say anything about this which makes it even more surprising.

  I believe that Varriount's suggestion to add not nil annotations where necessary is very good.

---

• Araq (orginal) [2015-03-19T23:55:24+01:00] view original

  @didlybom spare us the pathos please. That you need to pass "" to a 'var string' param is everywhere in the stdlib, 'nil' strings are never accepted. I think the tutorial mentions this too. "omg, it's so easy to crash" ... well yes, but it's also deterministic and not much of a problem when you learned the language. Note the deterministic here. That's completely different in C where it's almost always "happens randomly". That said, we're improving the situation anyway because every newbie gets it wrong.

---

• OderWat (orginal) [2015-03-20T00:57:48+01:00] view original

  @Varriount guess you are right. I was thinking about a simple case where nil obviously is wrong. Thats the not nil case I guess. Still it feels like it should be an "allow nil" case instead or a stringtype which is allowed to be nil and another which is not.

---

• didlybom (orginal) [2015-03-20T14:51:11+01:00] view original

  @Araq, I had to look up the meaning of "pathos", so thank you, I learned a new word today :-D

  Now that I know what pathos means I can say that I did not intend to "appeal to the emotions of the audience". Perhaps the "!" that I used may seem over-dramatic? It not my intention in any case. I was truly surprised that passing a nil string to a stdlib function can cause a crash. I do think that is an error that is easy to make (in fact you seem to agree since you said that newbies tend to get this wrong). I am surprised that the compiler does not warn about this. I went through the whole manual and several tutorials a while ago and I do not remember reading about this particular detail, but I surely missed it.

  In any case, as you said, once you know about it the issue is easy to avoid.

  May I ask in which cases would it make sense to leave a string uninitialized?

---

• dom96 (orginal) [2015-03-20T20:03:48+01:00] view original

  This will be solved in the future with not nil (once this feature is stable we can introduce it into the stdlib). For now the documentation should state that this parameter needs to be initialised, and yes I agree that it's not ideal.

---

• vbtt (orginal) [2015-03-20T20:42:36+01:00] view original

  It's nice that you get a traceback here (unlike C where I'd be left banging my head on the wall).

  It's exceptionally nice that this is deterministic! I did not know it was.

  However, it would be even nicer if the runtime error message was better - even if it just said something like 'write to uninitialized string "result"'. Is that possible?

  It seems 'not nil' will catch many of these at compile time? But even then some will slip through and better runtime errors will help.

---