2013-03-21 11 views
8

私は自分のコードで、多くのGoパッケージでそれを分割して、主に再利用性(独自のパッケージ内のそれぞれの "ビルディングブロック")を助けるために、スプリングクリーニングを行いました。Goプロジェクトをビルドするときに "nosplit stack overflow"?

インポートエラーを修正した後、突然プログラムが作成されないことがわかりました。 "go build"を実行すると、のnosplitスタックオーバーフローエラーが返されます。

ロボットmain.init:nosplitスタックオーバーフロー

120  guaranteed after split check in main.init 
    112  on entry to robot/web.init 
    104  on entry to robot/controller.init 
    96  on entry to robot/slam.init 
    88  on entry to robot/slam/hector.init 
    80  on entry to hectormapping/map/mapimages.init 
    72  on entry to hectormapping/map/maprep.init 
    64  on entry to hectormapping/map/mapproccontainer.init 
    56  on entry to hectormapping/scanmatcher.init 
    48  on entry to hectormapping/map/gridmap/occbase.init 
    40  on entry to hectormapping/map/gridmap/base.init 
    32  on entry to hectormapping/map/gridmap.init 
    24  on entry to github.com/skelterjohn/go%2ematrix.init 
    16  on entry to math.init 
    8  on entry to math.init┬À1 
    0  on entry to runtime.panicindex 
    -8  on entry to runtime.morestack00 

runtime.main:nosplitスタックオーバーフロー

120  guaranteed after split check in runtime.main 
    128  after runtime.main uses -8 
    120  on entry to main.init 
    112  on entry to robot/web.init 
    104  on entry to robot/controller.init 
    96  on entry to robot/slam.init 
    88  on entry to robot/slam/hector.init 
    80  on entry to hectormapping/map/mapimages.init 
    72  on entry to hectormapping/map/maprep.init 
    64  on entry to hectormapping/map/mapproccontainer.init 
    56  on entry to hectormapping/scanmatcher.init 
    48  on entry to hectormapping/map/gridmap/occbase.init 
    40  on entry to hectormapping/map/gridmap/base.init 
    32  on entry to hectormapping/map/gridmap.init 
    24  on entry to github.com/skelterjohn/go%2ematrix.init 
    16  on entry to math.init 
    8  on entry to math.init┬À1 
    0  on entry to runtime.panicindex 
    -8  on entry to runtime.morestack00 

誰もこれが何であるか知っていますか?いくつかのケースではa bug that supposedly is fixedであることを除いて、何が原因であろうと多くの文書を見つけることができません。ファイル構造は今あるようにコードの

いくつかは、「SRC」フォルダ内に新しいフォルダに分けた:

src/robot/main.go (main() lives here) 
src/robot/(...) (application-specific packages) 
src/hectormapping/(...) (stand-alone package used in "robot") 

私は、Windows 7(x64)の上に行く1.0.3を使用しています。

+0

あなたは安定しているのではなく、先のチップを試しましたか? –

+0

@ NickCraig-Woodいいえ、Windowsでこれを行う簡単な方法はありますか? – Mikke

+1

私はgo tipのための 'msi'についてはわかりませんが、コンパイラがあれば簡単にソースをビルドできます(http://golang.org/doc/install/source)。 –

答えて

5

これは、先端に固定されていると言われたhereと同じように思われる。対応する修正は、hereで確認できます。

私が見ているように問題を要約すると: Split stackingは、従来の固定メモリ領域の代わりにスタックを成長させるために使用されます。これは、必要なスタックメモリが実際に予約されているだけなので、より多くのスレッドを生成できるという利点があります。ここでの問題は、リンカーがスプリットスタックのプロローグを見つけられないため、スプリットスタックのメモリを偶発的に 'nosplit'として使用しない関数をマークすることにあるようです。これは、リンカーが間違ったスタック制限を計算することにつながります。リンカーは、スペースがないと思ってエラーメッセージをスローします。

悲しいことに、悲しいことに、チップバージョンを入手する唯一の方法は、あなた自身でコンパイルすることです。 Nick Craig-Woodがすでに述べたように、指示書hereを見つけることができます。本当に本当にアップグレードできない場合は、init関数に任意のローカル変数を割り当ててこの問題を回避しようとすることができます。しかし、これはもちろん非常に面倒です。

+0

あなたとNick Craig-Woodは正しいですが、問題はチップバージョンで修正されています! tipバージョンのインストールは大きな問題ではなく、 'hg clone'と' .bat'ファイルを実行するだけでした。 私は別の問題に遭遇しましたが、おそらく 'cgo'に関連し、この質問のトピックとは無関係です。 お返事ありがとうございました。また、別の回避策もありました。 – Mikke

関連する問題