www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Program exited with code -11

reply "Charles Hawkins" <dummy dummymail.com> writes:
My first attempt at a significant D program and I'm getting:
Error executing command run:
Program exited with code -11

How do I find out what that means?
Jun 22 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 02:34:17 UTC, Charles Hawkins wrote:

 How do I find out what that means?


Many return codes have a meaning in the linux documentation:

http://www.tldp.org/LDP/abs/html/exitcodes.html#EXITCODESREF

(it lists them as unsigned, but you got a signed result. 128 == 
-1, so -11 falls under the 128+ section in that table)


-11 means it exited with signal 11. Do "man 7 signal" in linux to 
get the signal documentation overview. One of the lines there is:

        SIGSEGV      11       Core    Invalid memory reference






Since you're a D newbie, I'm guessing you made the mistake of 
forgetting to new a class before using it:

class Foo {}

void main() {
    Foo foo;
    foo.something(); // this will segfault, killing the program
}


That's different than C++, D's classes are more like Java. You 
need to:

Foo foo = new Foo();

or

auto foo = new Foo();

so it isn't a null reference.
Jun 22 2015
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 23 June 2015 at 02:45:24 UTC, Adam D. Ruppe wrote:

 128 == -1


I'm sorry, I need to stop posting these things without thinking. 
-1 is actually 255 when you cast it, but I'm pretty sure the 
shell just does that subtraction from 128 because of the signal 
reservation codes. I stand by the rest of the post...
Jun 22 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
Thanks, Adam.  I'm coming from OCaml and haven't seen a seg fault 
in years.  Didn't recognize it. :D  Hopefully I can figure it out 
from here.
Jun 22 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins wrote:

 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.


Try to compile with either ldc or gdc and the -g flag, it should 
give you a backtrace. dmd seems to not like linux wrt backtraces.
Jun 22 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins wrote:

 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.


 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


Thanks.  I wish!  I haven't had any success in compiling with 
anything but dub.  gdc, dmd, rdmd always give me "module mylib is 
in file 'mylib.d' which cannot be read" on my "import mylib;" 
statement.  I've tried every permutation of -I and -L that I can 
think of.  It almost appears that one either uses dub for 
everything or nothing and I'm getting pretty frustrated with it 
as well.  Perhaps I should just go back to old-fashioned make 
files?
Jun 22 2015
next sibling parent reply "Baz" <bb.temp gmx.com> writes:
On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:

 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:

 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.


 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


 Thanks.  I wish!  I haven't had any success in compiling with 
 anything but dub.  gdc, dmd, rdmd always give me "module mylib 
 is in file 'mylib.d' which cannot be read" on my "import 
 mylib;" statement.  I've tried every permutation of -I and -L 
 that I can think of.  It almost appears that one either uses 
 dub for everything or nothing and I'm getting pretty frustrated 
 with it as well.  Perhaps I should just go back to 
 old-fashioned make files?


in dmd you have to pass
- the .lib/.a files a source
- the path to the lib source with '-I'. Sometimes when the path 
is not well indicated you get the error you talk about. This is 
because the '-I' path must follow carefully the structure of the 
lib, e.g

'import myLib.package.moduleThis':
the '-I' must point to the folder that contains the folder 
'myLib'.
Jun 23 2015
next sibling parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 07:25:05 UTC, Baz wrote:

 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:

 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:

 Thanks, Adam.  I'm coming from OCaml and haven't seen a seg 
 fault in years.  Didn't recognize it. :D  Hopefully I can 
 figure it out from here.


 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


 Thanks.  I wish!  I haven't had any success in compiling with 
 anything but dub.  gdc, dmd, rdmd always give me "module mylib 
 is in file 'mylib.d' which cannot be read" on my "import 
 mylib;" statement.  I've tried every permutation of -I and -L 
 that I can think of.  It almost appears that one either uses 
 dub for everything or nothing and I'm getting pretty 
 frustrated with it as well.  Perhaps I should just go back to 
 old-fashioned make files?


 in dmd you have to pass
 - the .lib/.a files a source
 - the path to the lib source with '-I'. Sometimes when the path 
 is not well indicated you get the error you talk about. This is 
 because the '-I' path must follow carefully the structure of 
 the lib, e.g

 'import myLib.package.moduleThis':
 the '-I' must point to the folder that contains the folder 
 'myLib'.


Sigh.  I'm probably doing something stupid.  I tried full paths:
dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d 
/home/charles/projects/d/mylib/build/libmylib.a
Same result.
myprog.d(4) Error: module mylib is in file 'mylib.d' which cannot 
be read
Statement in myprog is:
import mylib;

I used tab expansion so I'm confident everything is spelled 
correctly.  Since dub will compile it, I also tried copying and 
pasting its entry from the local packages file (leaves off the 
"source/mylib/").  Is there a way to find out what command dub is 
passing to dmd?
Jun 23 2015
next sibling parent "Charles Hawkins" <dummy dummymail.com> writes:
Ok, I think I've answered my own question.  dub -v tells me what 
I need to know.  Looks like I need to do a separate compile & 
link, make file like, just like the old days, or have a very 
complicated command line.  However, if there is a simple way to 
do the above, which it seems there should be, please let me know.
Jun 23 2015
prev sibling next sibling parent "Charles Hawkins" <dummy dummymail.com> writes:
 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


 ...I haven't had any success in compiling with anything but 
 dub.  gdc, dmd, rdmd always give me "module mylib is in file 
 'mylib.d' which cannot be read" on my "import mylib;" 
 statement. ...


 in dmd you have to pass
 - the .lib/.a files a source
 - the path to the lib source with '-I'. Sometimes when the 
 path is not well indicated you get the error you talk about. 
 This is because the '-I' path must follow carefully the 
 structure of the lib, e.g

 'import myLib.package.moduleThis':
 the '-I' must point to the folder that contains the folder 
 'myLib'.


...
 dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d 
 /home/charles/projects/d/mylib/build/libmylib.a
 Same result.
 myprog.d(4) Error: module mylib is in file 'mylib.d' which 
 cannot be read
 Statement in myprog is:
 import mylib;
...


I used -v to imitate what dub is doing and that works, except 
that I don't see any reference to the compiled library itself.  
Apparently it is recompiling the library as well, which defeats 
the main purpose of having a library in the first place.

And gdc doesn't seem to recognize std.experimental.logger which 
is what I used in converting all my debugging code.  Sigh.
Jun 23 2015
prev sibling parent reply "anonymous" <anonymous example.com> writes:
On Tuesday, 23 June 2015 at 07:57:26 UTC, Charles Hawkins wrote:


 Sigh.  I'm probably doing something stupid.  I tried full paths:
 dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d


What's that plus sign doing there? Looks wrong.


 /home/charles/projects/d/mylib/build/libmylib.a
 Same result.
 myprog.d(4) Error: module mylib is in file 'mylib.d' which 
 cannot be read
 Statement in myprog is:
 import mylib;
Jun 23 2015
parent "Charles Hawkins" <dummy dummymail.com> writes:
On Tuesday, 23 June 2015 at 11:18:07 UTC, anonymous wrote:

 On Tuesday, 23 June 2015 at 07:57:26 UTC, Charles Hawkins wrote:


 Sigh.  I'm probably doing something stupid.  I tried full 
 paths:
 dmd -I+/home/charles/projects/d/mylib/source/mylib/ myprog.d


 What's that plus sign doing there? Looks wrong.


 /home/charles/projects/d/mylib/build/libmylib.a
 Same result.
 myprog.d(4) Error: module mylib is in file 'mylib.d' which 
 cannot be read
 Statement in myprog is:
 import mylib;




Hey, I was right!  Something stupid!  I really don't think I made 
it up.  Either I copied from some example that was in error, or 
was looking at something for another language (I've been looking 
at several lately) that added to a search path.  In any event, I 
was obviously confused.

Thanks, all!  I think I'm back on track now.  In fact, I've got 
several test programs working with my library.  It isn't so large 
that compiling it every time was that big of a deal, but nice to 
know I don't have to.
Jun 23 2015
prev sibling parent "Baz" <bb.temp gmx.com> writes:
On Tuesday, 23 June 2015 at 07:25:05 UTC, Baz wrote:

 in dmd you have to pass
 - the .lib/.a files a source


I meant "as source", actually. you pass the .lib or .a file 
without switch as if it's a main source.
Jun 23 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:

 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:

 [...]


 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


 Thanks.  I wish!  I haven't had any success in compiling with 
 anything but dub.  gdc, dmd, rdmd always give me "module mylib 
 is in file 'mylib.d' which cannot be read" on my "import 
 mylib;" statement.  I've tried every permutation of -I and -L 
 that I can think of.  It almost appears that one either uses 
 dub for everything or nothing and I'm getting pretty frustrated 
 with it as well.  Perhaps I should just go back to 
 old-fashioned make files?


you can instruct dub to use other compilers with the --compiler 
option
valid options include dmd,ldc,gdc,gdmd,ldmd
Jun 23 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins wrote:

 On Tuesday, 23 June 2015 at 03:31:37 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 03:29:14 UTC, Charles Hawkins 
 wrote:

 [...]


 Try to compile with either ldc or gdc and the -g flag, it 
 should give you a backtrace. dmd seems to not like linux wrt 
 backtraces.


 Thanks.  I wish!  I haven't had any success in compiling with 
 anything but dub.  gdc, dmd, rdmd always give me "module mylib 
 is in file 'mylib.d' which cannot be read" on my "import 
 mylib;" statement.  I've tried every permutation of -I and -L 
 that I can think of.  It almost appears that one either uses 
 dub for everything or nothing and I'm getting pretty 
 frustrated with it as well.  Perhaps I should just go back to 
 old-fashioned make files?


 you can instruct dub to use other compilers with the --compiler 
 option
 valid options include dmd,ldc,gdc,gdmd,ldmd


Ah, a "sort of" hidden option.  I've only been typing "dub" and 
thus, "dub --help".  Didn't think to do "dub build --help".

Is there a quick way to get gdc to recognize 
std.experimental.logger?  I'm already spoiled by it.  Choosing 
between it and a backtrace is difficult.
Jun 24 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 24 June 2015 at 07:52:10 UTC, Charles Hawkins wrote:

 On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins 
 wrote:

 [...]


 you can instruct dub to use other compilers with the 
 --compiler option
 valid options include dmd,ldc,gdc,gdmd,ldmd


 Ah, a "sort of" hidden option.  I've only been typing "dub" and 
 thus, "dub --help".  Didn't think to do "dub build --help".

 Is there a quick way to get gdc to recognize 
 std.experimental.logger?  I'm already spoiled by it.  Choosing 
 between it and a backtrace is difficult.


I believe it's available as a dub package albeit outdated, should 
be roughly similar though.
Jun 24 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Wednesday, 24 June 2015 at 16:21:47 UTC, weaselcat wrote:

 On Wednesday, 24 June 2015 at 07:52:10 UTC, Charles Hawkins 
 wrote:

 On Wednesday, 24 June 2015 at 06:54:57 UTC, weaselcat wrote:

 On Tuesday, 23 June 2015 at 06:50:28 UTC, Charles Hawkins 
 wrote:

 [...]


 you can instruct dub to use other compilers with the 
 --compiler option
 valid options include dmd,ldc,gdc,gdmd,ldmd


 [...]

 Is there a quick way to get gdc to recognize 
 std.experimental.logger?  I'm already spoiled by it.  Choosing 
 between it and a backtrace is difficult.


 I believe it's available as a dub package albeit outdated, 
 should be roughly similar though.


Thanks.  I've changed to thread topic to "Help the old man learn 
D". :)  logger package allows those statements to compile with 
gdc although I'm now getting lots of errors saying "undefined 
identifier format" even though I'm importing std.format, but not 
all of them are being flagged.  Once I get it to where those are 
the only errors, perhaps I can figure it out.

I'm converting one of my OCaml programs and I have a class (call 
it Dispatcher) that uses callbacks.  With OCaml, it didn't matter 
if the callbacks were functions or methods but apparently D makes 
a distinction, which I can understand.  I guess this is an 
opinion question, but should I duplicate Dispatcher's register 
functions and data structures to handle both, or do I define 
global functions that call the called-back methods (there's only 
one instance of the called-back class) and pass those to 
Dispatcher?  Or is there a better way?
Jun 26 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:

 Thanks.  I've changed to thread topic to "Help the old man 
 learn D". :)  logger package allows those statements to compile 
 with gdc although I'm now getting lots of errors saying 
 "undefined identifier format" even though I'm importing 
 std.format,


I believe the `format` method used to be in `std.string` a few 
releases ago, try importing that one.
Jun 26 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote:

 On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:

 Thanks.  I've changed to thread topic to "Help the old man 
 learn D". :)  logger package allows those statements to 
 compile with gdc although I'm now getting lots of errors 
 saying "undefined identifier format" even though I'm importing 
 std.format,


 I believe the `format` method used to be in `std.string` a few 
 releases ago, try importing that one.


Thank you!  That explains why it wasn't flagging all of them 
since some of my modules import std.string as well.

I think I've answered my own question regarding the callbacks as 
well.  I realized that the only reason I made those sections of 
code classes in OCaml, even though there would only be one 
instance of them, was so I could do forward referencing.  I'm 
hoping that I'll get function pointers instead of delegate 
pointers if I convert the class back to a module.
Jun 26 2015
parent reply "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 15:33:25 UTC, Charles Hawkins wrote:

 On Friday, 26 June 2015 at 14:52:51 UTC, Marc Schütz wrote:

 On Friday, 26 June 2015 at 14:39:05 UTC, Charles Hawkins wrote:

[...]




 I think I've answered my own question regarding the callbacks 
 as well.  I realized that the only reason I made those sections 
 of code classes in OCaml, even though there would only be one 
 instance of them, was so I could do forward referencing.  I'm 
 hoping that I'll get function pointers instead of delegate 
 pointers if I convert the class back to a module.


Sorry for talking to myself, but I'm hoping someone will help me 
out.  The above idea doesn't work.  It appears that only the main 
program file is going to have function pointers while modules and 
classes will have delegates.  So, does a library that uses 
callbacks need 2 callback register functions as well as parallel 
storage mechanisms, or is there a fairly simple way to make it 
polymorphic?  I was hoping a newbie would be able to use this 
library, but not many newbies are going to understand this.  I 
suppose I could tell them to call registerFunction and if they 
get a compiler error, then call registerDelegate?  Or am I 
missing something?
Jun 26 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote:

 Sorry for talking to myself, but I'm hoping someone will help 
 me out.  The above idea doesn't work.  It appears that only the 
 main program file is going to have function pointers while 
 modules and classes will have delegates.  So, does a library 
 that uses callbacks need 2 callback register functions as well 
 as parallel storage mechanisms, or is there a fairly simple way 
 to make it polymorphic?  I was hoping a newbie would be able to 
 use this library, but not many newbies are going to understand 
 this.  I suppose I could tell them to call registerFunction and 
 if they get a compiler error, then call registerDelegate?  Or 
 am I missing something?


I don't fully understand what you're doing, but functions can 
easily be turned into delegates using std.functional.toDelegate 
[1]:

     import std.functional : toDelegate;
     registerDelegate((&topLevelFunction).toDelegate);
Jun 26 2015
parent "Charles Hawkins" <dummy dummymail.com> writes:
On Friday, 26 June 2015 at 17:11:54 UTC, Marc Schütz wrote:

 On Friday, 26 June 2015 at 16:57:14 UTC, Charles Hawkins wrote:

[...]


 I don't fully understand what you're doing, but functions can 
 easily be turned into delegates using std.functional.toDelegate 
 [1]:

     import std.functional : toDelegate;
     registerDelegate((&topLevelFunction).toDelegate);




Thanks, Marc.  That should work if my brute force duplicate code 
doesn't.

Thanks to everyone, at long last my project compiles with dmd.  
It crashes right away, but that's not unexpected since I haven't 
used pointers in several years.  Unfortunately, compiling with 
gdc spits out a bunch of errors regarding getopt so I'm back to 
sprinkling log statements to find the problem.
Jun 26 2015