Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
I've already killed a week trying to solve a mysterious problem in a project of mine and I am out of ideas.
I wrote a Go package intended to play sounds which wraps OpenAL... pretty basic stuff. I got it working on my Xubuntu 14.04 (32-bit), so I booted into Windows (7, also 32-bit) in order to port it... and that's where the problems started.
Whenever I tried to use my audio package, the program crashed with c0000005. I tried to run it through gdb and was surprised to find out that it worked without a problem, it even played my test sound.
Time passed and not knowing what to do, I downloaded the OpenAL Soft source code and started adding printfs - and discovered the exact line it crashed on:
http://repo.or.cz/w/openal-soft.git/blob/HEAD:/Alc/backends/dsound.c#l361
For those lazy to click the link (or if the link stopped working), it's a call to DirectSoundCreate. Running through the debugger again, I saw my prints right before and after the call, and 4 new threads being created between them.
These are the relevant things in the Go file:
package audio
/*
#cgo CFLAGS: -I"../libraries/include"
#cgo windows,386 LDFLAGS: ../libraries/lib/windows/x86/OpenAL32.dll
#cgo windows,amd64 LDFLAGS: ../libraries/lib/windows/x64/OpenAL32.dll
#cgo linux LDFLAGS: -lopenal
#include "audio.h"
*/
import "C"
import (
"errors"
)
var context *C.ALCcontext
func Init() error {
context = C.initAudio() // it crashes on this line
if context == nil {
return errors.New("could not initialize audio")
}
SetActiveListener(NewListener())
return nil
}
And here's the C file actually making the OpenAL calls:
#include "audio.h"
#include <string.h>
#include <stdio.h>
ALCcontext* initAudio() {
ALCdevice* device = alcOpenDevice(NULL); // crashes here
if (device == NULL) {
return NULL;
}
ALCcontext* context = alcCreateContext(device, NULL);
if (!alcMakeContextCurrent(context)) {
return NULL;
}
return context;
}
Last but not least, if I do the exact same thing in pure C (literally just adding main into the file I posted and calling initAudio), it works.
My question is obvious: What the ##!$ is going on?
edit:
Some other things which might be worth mentioning:
I created a new project completely separate from the previous one, in which I have the two files I posted earlier (with different paths for the linker in the Go file, obviously) and the main Go file which does only one thing: call audio.Init. Regardless of which dll I try (I tried the "official" one from http://openal.org, the precompiled version of OpenAL Soft and two versions I compiled myself, one with MinGW and one with Visual Studio), it behaves the same. I also tried to call runtime.LockOSThread at the start of audio.Init, but it didn't help.
Also, I sent the compiled program to my two friends, one running Windows 8 and one with Windows 7 (both 64-bit). The one with Windows 8 said it worked, the one with 7 said it crashed. However, if we tried to compile it from source on the latter machine, with the 64-bit toolchain, it worked.
edit #2:
I just tried to compile OpenAL Soft from source again - first with Visual Studio and then with MinGW - and then link my independent project I mentioned earlier with the library files (OpenAL32.lib from VS and libOpenAL32.dll.a from MinGW) instead of the DLL directly (since that is... the more correct way I guess?)
The result with VS:
It failed during linking, with the following message:
# command-line-arguments
C:\Users\Milan\AppData\Local\Temp\go-build078751523/audiot/audio.a(_all.o): malf
ormed pe file: unexpected flags 0xe0500020 for PE section .text
audiot/audio._Cfunc_initAudio: undefined: _cgo_e0a3be4f138e_Cfunc_initAudio
The result with MinGW:
It succeeded to compile and run, and while it didn't prevent the crash, at least it printed something out:
fatal error: unexpected signal during runtime execution
[signal 0xc0000005 code=0x1 addr=0x420f85 pc=0x42874c]
runtime stack:
invalid spdelta 96655 -1
runtime: unexpected return pc for _cgo_ec587e40eeca_Cfunc_initAudio called from
0x42874800
runtime.throw(0x455dc0)
c:/go/src/pkg/runtime/panic.c:520 +0x71
runtime.sigpanic()
c:/go/src/pkg/runtime/os_windows.c:352 +0x46
invalid spdelta 96655 -1
runtime: unexpected return pc for _cgo_ec587e40eeca_Cfunc_initAudio called from
0x42874800
_cgo_ec587e40eeca_Cfunc_initAudio()
?:0 +0xc
goroutine 16 [syscall]:
runtime.cgocall(0x428740, 0x533f64)
c:/go/src/pkg/runtime/cgocall.c:143 +0xed fp=0x533f58 sp=0x533f2c
audiot/audio._Cfunc_initAudio(0x42e340)
audiot/audio/_obj/_cgo_defun.c:53 +0x37 fp=0x533f64 sp=0x533f58
audiot/audio.Init(0x0, 0x0)
C:/Users/Milan/Desktop/Dropbox/Projekty/Go/src/audiot/audio/at.go:23 +0x
3c fp=0x533f90 sp=0x533f64
main.main()
c:/Users/Milan/Desktop/Dropbox/Projekty/Go/src/audiot/main.go:10 +0x29 f
p=0x533f9c sp=0x533f90
runtime.main()
c:/go/src/pkg/runtime/proc.c:247 +0x11e fp=0x533fd0 sp=0x533f9c
runtime.goexit()
c:/go/src/pkg/runtime/proc.c:1445 fp=0x533fd4 sp=0x533fd0
created by _rt0_go
c:/go/src/pkg/runtime/asm_386.s:101 +0x102
goroutine 17 [syscall]:
runtime.goexit()
c:/go/src/pkg/runtime/proc.c:1445
exit status 2
I also thought it can't hurt to post the specifics of my toolchain:
$ gcc --version
gcc.exe (GCC) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
$ go version
go version go1.3 windows/386
And let's not forget Visual Studio 2013 Express
I just learnt Go 1.3.1 came out, so I tried updating... and the problem disappeared. (argh!)
I guess it was a compiler bug then. Anyway, thanks to everyone who tried to help, I really appreciate it.
It might be related to Thread Switching:
The solution could be to use LockOSThread
http://golang.org/pkg/runtime/#LockOSThread
You can read more about it here:
https://code.google.com/p/go-wiki/wiki/LockOSThread
Also your Init function has capital I if you are trying to initialize the library it has to be lower case.
Related
I've installed GnuCOBOL 2.2 on my Ubuntu 17.04 system. I've written a basic hello world program to test the compiler.
1 IDENTIFICATION DIVISION.
2 PROGRAM-ID. HELLO-WORLD.
3 *---------------------------
4 DATA DIVISION.
5 *---------------------------
6 PROCEDURE DIVISION.
7 DISPLAY 'Hello, world!'.
8 STOP RUN.
This program is entitled HelloWorld.cbl. When I compile the program with the command
cobc HelloWorld.cbl
HelloWorld.so is produced. When I attempt to run the compiled program using
cobcrun HelloWorld
I receive the following error:
libcob: entry point 'HelloWorld' not found
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
According to the official manual of GNUCOBOL, you should compile your code with:
cobc -x HelloWorld.cbl
then run it with
./HelloWorld
You can also read GNUCOBOL wiki page which contains some exmaples for further information.
P.S. As Simon Sobisch said, If you change your file name to HELLO-WORLD.cbl to match the program ID, the same commands that you have used will be ok:
cobc HELLO-WORLD.cbl
cobcrun HELLO-WORLD
Can anyone explain to me what an entry point is in GnuCOBOL, and perhaps suggest a way to fix the problem and successfully execute this COBOL program?
An entry point is a point where you may enter a shared object (this is actually more C then COBOL).
GnuCOBOL generates entry points for each PROGRAM-ID, FUNCTION-ID and ENTRY. Therefore your entry point is HELLO-WORLD (which likely gets a conversion as - is no valid identifier in ANSI C - you won't have to think about this when CALLing a program as the conversion will be done internal).
Using cobcrun internally does:
search for a shared object (in your case HelloWord), as this is found (because you've generated it) it will be loaded
search for an entry point in all loaded modules - which isn't found
There are three possible options to get this working:
As mentioned in Ho1's answer: use cobc -x, the reason that this works is because you don't generate a shared object at all but a C main which is called directly (= the entry point doesn't apply at all)
preload the shared object and calling the program by its PROGRAM-ID (entry point), either manually with COB_PRE_LOAD=HelloWorld cobcrun HELLO-WORLD or through cobcrun (option available since GnuCOBOL 2.x) cobcrun -M HelloWorld HELLO-WORLD
change the PROGRAM-ID to match the source name (either rename or change the source, I'd do the second: PROGRAM-ID. HelloWorld.)
Problem
I have some half-year old c-programs I was working on and had hoped that I could continue working on them now. I did installed windows 10 (64-bit) right after that, so I thought could be a problem but the programs have run on windows 10 since then.
About 2 months ago, I could build with the make-file and run the executables but when I tried again today, it seems to me like the executables are not running. I have now also tried updating cygwin and (I think) all relevant packages.
I have googled if there are any important changes to cygwin but I didn't really find anything.
Details
When I try running any program nothing happens for a long while at the ./executeables/helloworld.exe line and then eventually producing the error:
$ make 1
gcc 1-helloworld.c -o ./executeables/helloworld.exe -lncurses
./executeables/helloworld.exe
0 [sig] make 7332 get_proc_lock: Couldn't acquire sync_proc_subproc for(5, 1), last 7, Win32 error 0
1324 [sig] make 7332 proc_subproc: couldn't get proc lock. what 5, val 1
After this, nothing happens and I cannot even stop the process with ctrl+C so I have to end "make.exe" (which oddly enough consists of 2 processes) with task manager. The terminal then says nothing more than
makefile:2: recipe for target '1' failed
make: *** [1] Error 1
So I'm guessing there is a problem with getting a mutex or a lock from windows for creating a process, but I have no clue why this would happen.
Code
The example in this try uses this code for a hello world program, but it's the same for the more complex programs as well.
#include <ncurses.h>
#include <string.h>
int main() {
char *message="Hello World";
int row,col;
int len = strlen(message);
initscr();
getmaxyx(stdscr, row, col); //screensize
mvprintw(row/2, (col-len)/2, "%s", message); //center of screen
getch();
refresh();
endwin();
return 0;
}
Have anyone seen this problem before?
Avast antivirus was preventing the program from running correctly. Disabling it made everything run perfectly. I finally found the answer in this thread:
Netbeans 8.1 IDE compiles and builds C programs but does not show their output
note:
Since it is not marked as an answer to the question in that thread and because that question is not explicitly focusing the same error (although presents the same error), I will keep my question instead of marking it as a duplicate.
Thank you, Sheshadri Iyengar for providing the solution.
I am trying to play a wav file in a very simple program that looks like this, currently attempting to use nim-csfml:
import csfml_audio
var alarmsong = newMusic("alarm.wav")
alarmsong.play()
but it appears to be relying on the existence of libcsfml.audio, and while my program compiles just fine, when I try to actually run it I get an error
| => ./alarm
could not load: libcsfml-audio.so
(I have a libcsfml-audio.dylib instead, being that I used the OSX shared libraries for csfml/sfml)
Is there some other way to play a .wav file in Nim?
Edit 1:
After the PR made by #def-, I now get a different, slightly more comforting error, which is probably due to some poor understanding of how nim deals with shared libraries:
| => ./alarm
could not load: libcsfml-audio.dylib
I added path = "/usr/local/lib" to my nim.cfg file, but it didn't seem to be affect anything. I also exported $LD_LIBRARY_PATH="/usr/local/lib" (/usr/local/bin is where libcsfml-audio.dylib is.), and tried compilation through
nim c alarm.nim --clib:/usr/local/lib/libcsfml-audio.dylib
Thanks for the help!
This program would just exit immediately; you need to keep it alive while the sound plays. Append this to the program:
import csfml_system
while alarmsong.status == SoundStatus.Playing:
sleep 100.milliseconds
For nim-csfml to work you'll need SFML 2.1 and CSFML 2.1. Also, it seems that nim-csfml is actually broken for Mac OS X, so I've made a pull request with a fix: https://github.com/BlaXpirit/nim-csfml/pull/4
Other modules that could play sound are sdl_mixer, sdl2/audio and allegro5.
As an OSX-only alternative without using any libraries, by calling the afplay binary:
import osproc
discard execProcess("afplay", ["file.wav"])
Edit1:
When Nim reports "could not load: libcsfml-audio.dynlib" that could also mean that one of the dependencies of that library are missing or in a wrong version. Especially SFML 2.2 doesn't work with CSFML 2.1. Make sure libsfml-audio.dynlib is in your LD_LIBRARY_PATH as well. If that doesn't work either, you could try to compile and run a regular C CSFML example like this one: https://gist.github.com/def-/fee8bb041719337c8812
Compile it with clang -o mainpage -lcsfml-graphics -lcsfml-audio -lGL -lGLEW mainpage.c to see the errors/warnings about missing libraries.
I am in a HUGE depression now! I spend 2 days trying to use boost.python . PLEASE guide me! I will explain what I did.
I have Winows 7 64 bit.
The Python is 64 bit 2.7.3 installed at C:\Python27_amd64.
Now, I take boost_1_54_0.zip and unzip in F: directory.
The I use cmd.
bootstrap
this creates project-config.jam. I edit it and insert
using msvc : 9.0 ;
using python : 2.7 : C:\Python27_amd64\python : C:\Python27_amd64\include : C:\Python27_amd64\libs ;
Now i do
.\b2
This process runs for 20 something minutes and I am told that boost has successfully been build.
After that I install boost binaries from http://sourceforge.net/projects/boost/files/boost-binaries/
The binaries get installed in C:\local\boost_1_54_0.
Now I want to create a General project.
Now, I use the code given for embedding python in C++ here
#include <boost/python.hpp>
#include <boost/detail/lightweight_test.hpp>
#include <iostream>
namespace py = boost::python;
using namespace std;
int main()
{
// Initialize the interpreter
Py_Initialize();
py::object main_module = py::import("__main__");
py::object main_namespace = main_module.attr("__dict__");
py::exec("print 'Hello, world'", main_namespace);
py::exec("print 'Hello, world'[3:5]", main_namespace);
py::exec("print '.'.join(['1','2','3'])", main_namespace);
}
I setup the header files and library in VC++ directories to F:\boost_1_54_0\boost_1_54_0 and F:\boost_1_54_0\boost_1_54_0\stage\lib respectively.
I also setup project-->properties-->configuration properties-->C/C++-->General-->Additional Include directories to C:\Python27_amd64\include
Likewise, I also setup project-->properties-->configuration properties--> Linker--> General to C:\Python27_amd64\libs;"C:\local\boost_1_54_0\lib64-msvc-9.0" .
Now when I compile using x64 debugger. It gives me an error
Unhandled exception at 0x00000000 in test8.exe: 0xC0000005: Access violation at location 0x0000000000000000.
I am struck since last 2 days...but thats the closest I have been since then. please help me!
So you mean a runtime error, right?
I think you should first ensure, that there is no exception thrown by boost::python itself.
First try to set the try block around you python calls with a catch(...)
If exception is caught it is most probably the boost::python::error_already_set exception.
So, you then should decode it like here
I m using gdb on a aix shared lib running on aix 5.3?
When i try to run gdb for this file
i get a error message saying ""Architecture of file not recognized"
Don't know how to get this fixed.
Does anybody know why i get this message ""Architecture of file not recognized"?.
gdb runs fine on other executables compiled by xlc.
Is there some option that i might have used while compiling , which is not compatible with GDB.some processor specific option.
I compiled the shared lib w xlc v9.0 for aix.
Thanks.
You don't run GDB on a shared library, you run it on an executable.
If the executable loads your shared library, GDB will know about it.
void
set_gdbarch_from_file (bfd *abfd)
{
struct gdbarch_info info;
struct gdbarch *gdbarch;
gdbarch_info_init (&info);
info.abfd = abfd;
info.target_desc = target_current_description ();
gdbarch = gdbarch_find_by_info (info);
if (gdbarch == NULL)
error (_("Architecture of file not recognized."));
deprecated_current_gdbarch_select_hack (gdbarch);
}
This is the actual GDB code in question (gdb/arch-utils.c:530-544).
The information passed to the gdbarch pointer seems to be invalid. This is caused by gdb_find_by_info returning a NULL pointer and that is caused by find_arch_by_info (gdb/gdbarch.c:3656) returning a NULL pointer.
It basically means what it says: GDB could not identify the architecture of the file. This seems to be a common problem for xlc, even on recent gdb versions.
XLC and gdb are, as far i remember and understand, not very good when it comes down to compatability terms (AIX support is minimal), you might try using the Gnu C Compiler .You might look at the GDB sources for VERY specific information (that i can't really give you).
Here is a link to gcc-AIX specifics.