signal: segmentation fault before 'main.main' about qml

[niemeyer]

What's the panic message?

[niemeyer]

Please run it with:

export GOTRACEBACK=2

[comaldave]

Thanks for the suggestion. As you can see, there is no panic, there is no
helpful error message. Using the gdb I only found that it happens before
'main.main'

david@debian:/local/src/dasa.cc/universe/senet/test2$ export GOTRACEBACK=2
david@debian:/local/src/dasa.cc/universe/senet/test2$ ./test2
Segmentation fault

On Tue, Apr 1, 2014 at 1:56 PM, Gustavo Niemeyer
[email protected]:

Please run it with:

export GOTRACEBACK=2

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-39244164
.

[slimsag]

Gustavo,
I'm the author of the azul3d.org/v0/native/freetype package mentioned here. A more simple program can reproduce the issue (removing either one of the imports makes the program work):

package main

import (
    _ "azul3d.org/v0/native/freetype"
    _ "gopkg.in/v0/qml"
)

func main() {
}

which results in just a segfault with no other information, gdb also has little to say:

(gdb) run
Starting program: /home/stephen/Desktop/godev/bin/qmlft 

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) up
#1  0x0000000000000000 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.

I'll try to investigate further as time allows.

[slimsag]

azul3d.org/v0/native/freetype links against a static version of libfreetype kept in the repo (freetype_linux_amd64.syso) and it seems that if I delete that and link against my system's freetype library then it works fine.

I think the version of freetype used is binary-incompatible with the one QT 5 probably uses (or something like that).

Stephen

[comaldave]

I am thinking that the only reason I had this problem is because I would
rather use someone else s code than write my own. I appreciate your finding
this problem so quickly, I expect it will be okay in v1 but I am still
concerned that the error code was so lacking in information. I am hoping
you can let the problem remain in the v0 of the library long enough for the
authors of go1.3 to devise some way of reporting the error in a bit more
informative way, or even detecting the error during compile or link time.

https://code.google.com/p/go/issues/detail?id=7678

On Wed, Apr 2, 2014 at 8:25 AM, stephengutekanst
[email protected]:

azul3d.org/v0/native/freetype links against a static version of
libfreetype kept in the repo (freetype_linux_amd64.syso) and it seems that
if I delete that and link against my system's freetype library then it
works fine.

I think the version of freetype used is binary-incompatible with the one
QT 5 probably uses (or something like that).

Stephen

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-39329276
.

[slimsag]

Gustavo,

You can close this issue now, sorry for the bother here. I've made azul3d.org/v0/native/freetype link against the system library and fixed the issue. (more details at https://code.google.com/p/azul3d/issues/detail?id=44)

Stephen

[niemeyer]

@stephengutekanst Thanks for following this through, and getting a fix in place so quickly.