問題タブ [glibc]

.a ファイルから、どのバージョンの glibc が予想されるか、.a のビルド時に使用されたかを調べる方法はありますか?

このスクリプトからの出力の最後に、次のエラーメッセージが表示されます。

*glibcが検出されました* perl：munmap_chunk（）：無効なポインター：0x0000000000b362e0 *** =======バックトレース：=========
/lib64/libc.so.6 [0x7fb84952fc76]
...
= ======メモリマップ：========
00400000-0053d000 r-xp 00000000 08:01 182002 / usr / local / bin / perl
.. ..

これはバグによるものですか？

perl -V：

私のperl5（リビジョン5バージョン12サブバージョン0）構成の要約：

プラットフォーム：
osname = linux、osvers = 2.6.31.12-0.2-desktop、archname = x86_64-linux uname ='linux linux1 2.6.31.12-0.2-desktop＃1 smp preempt 2010-03-16 21:25:39 +0100 x86_64 x86_64 x86_64 gnulinux'config_args ='-Dnoextensions = ODBM_File'ヒント=推奨、useposix = true、d_sigaction = define useithreads = undef、usemultiplicity = undef useperlio = define、d_sfio = undef、uselargefiles = define、usesocks = undef = define、uselongdouble = undef usemymalloc = n、bincompat5005 = undef
コンパイラ：
cc ='cc'、ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I / usr / local / include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS = 64'、optimize ='-O2'、cppflags ='-fno- strict-aliasing -pipe -fstack-protector -I / usr / local / include'ccversion =''、gccversion ='4.4.1 [gcc-4_4-branch Revision 150839]'、gccosandvers =''intsize = 4、longsize = 8、ptrsize = 8、doublesize = 8、byteorder = 12345678 d_longlong = define、longlongsize = 8、d_longdbl = define、longdblsize = 16 ivtype ='long'、ivsize = 8、nvtype ='double'、nvsize = 8、Off_t = 'off_t'、lseeksize = 8 alignbytes = 8、prototype = define
リンカーとライブラリ：
ld ='cc'、ldflags ='-fstack-protector -L / usr / local / lib'libpth = / usr / local / lib / lib / usr / lib / lib64 / usr / lib64 / usr / local / lib64 libs = -lnsl -ldl -lm -lcrypt -lutil -lc perllibs = -lnsl -ldl -lm -lcrypt -lutil -lc libc = / lib / libc-2.10.1.so、so = so、useshrplib = false、libperl = libperl .a gnulibc_version = '2.10.1'ダイナミックリンク：dlsrc = dl_dlopen.xs、dlext = so、d_dlsymun = undef、ccdlflags ='-Wl、-E' cccdlflags ='-fPIC'、lddlflags ='-shared -O2- L / usr / local / lib -fstack-protector '

このバイナリの特徴（libperlから）：コンパイル時のオプション：PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_PERLIO USE_PERL_ATOFlinux
で構築2010年4月15日13:25:46@INC： 0 / x86_64-linux /usr/local/lib/perl5/site_perl/5.12.0/usr/local/lib/perl5/5.12.0/x86_64-linux/usr/local/lib/perl5/5.12.0。

Android 1.6 または 2.1 を起動しようとしたときに、このトレースを取得しました。Android 1.5 は問題なく動作しています。各 SDK を再インストールしようとしましたが、機能させる方法がありません。これらの AVD を Eclipse プラグインで作成しました。

複数の Linux ディストリビューションで実行できるバイナリ パッケージを構築しようとしています。現在、Ubuntu 10.04 でビルドされていますが、Ubuntu 8.04 では次のエラーで失敗します。

この問題を解決するための好ましい方法は何ですか? 古い glibc を新しいボックスにインストールしてビルドする方法はありますか? それとも古いディストリビューションでビルドする必要がありますか? また、古い glibc に対してビルドした場合、新しい glibc でも動作しますか?

または、代わりに、問題を解決するためにインストールできる便利なコンパイラ フラグまたはパッケージがいくつかありますか?

printf/fprintf/sprintf ファミリは、その書式指定子で幅フィールドをサポートしています。(非ワイド) char 配列引数の場合には疑問があります。

幅フィールドはバイトまたは文字を意味するはずですか?

char 配列が (たとえば) 生の UTF-8 文字列に対応している場合、(正しい事実上の) 動作は何ですか? （通常、ワイド文字型を使用する必要があることはわかっていますが、それは重要ではありません）

たとえば、

その関数は、5 バイト (プレーンな C 文字) だけを出力しようとすることになっていますか (2 バイトがテキスト文字になる場合は、ミスアラインメントやその他の問題の責任を負います) ?

それとも、配列の「テキスト文字」の長さを計算しようとすることになっていますか? （現在のロケールに従ってデコードしますか？）（この例では、文字列に 4 つの Unicode 文字があることがわかるため、パディング用のスペースが追加されます）。

更新:私は答えに同意します.printfファミリがプレーンC文字とバイトを区別しないのは論理的です. 問題は、ロケールが以前に設定されていて、(今日最も使用されている) LANG/LC_CTYPE=en_US.UTF-8 がある場合、私の glibc がこの概念を完全に尊重していないように見えることです。

適例：

そのため、非 POSIX-C ロケールが設定されている場合でも、printfは幅をカウントするための正しい概念を持っているようです: バイト (c プレーン文字) であり、ユニコード文字ではありません。それはいいです。ただし、彼のロケールでデコードできない char 配列を指定すると、静かにパニックが発生します (中止 - 最初の '|' の後に何も出力されません - エラーメッセージなし)... 幅をカウントする必要がある場合のみ。必要な/必要なときに、utf-8 から文字列をデコードしようとする理由がわかりません。これは glibc のバグですか?

glibc 2.11.1 (Fedora 12) でテスト済み (glibc 2.3.6 も)

注：端末の表示の問題とは関係ありません- od にパイプすることで出力を確認できます：これ$ ./a.out | od -t cx1が私の出力です：

UPDATE 2 (2015 年 5 月) : この疑わしい動作は、新しいバージョンの glibc で修正されました (2.17 以降のようです)。それは私にとってはうまくいきglibc-2.17-21.fc19ます。

最後にプログラムを実行するとfclose(outputFile); 、エラーが発生します。glibc が検出されました...破損した二重リンク リスト

ただし、これについて紛らわしいのは、私がそのfclose(inputFile);真上にあり、正常に機能することです。助言がありますか？

gccは.cファイルでは正常に動作しますが、.cppファイルでは次のように失敗します。

$ gcc：'cc1plus'を実行しようとしてエラーが発生しました：execvp：そのようなファイルまたはディレクトリはありません

g ++は次のように言って失敗します：

$ g ++：コマンドが見つかりません。

C ++ファイルをコンパイルできるようにするにはどうすればよいですか？

1. 2008年の投稿によると（現在は見つかりません）、glibcヒープチェックはマルチスレッド環境では機能しません。2010年も今もそうですか？
2. ヒープチェックはデフォルトで有効になっていますか？（gcc 4.1.2）？MALLOC_CHECK_を設定せず、mcheck（）の呼び出しに気づいていませんが、バックトレースでダブルフリーのglibcエラーが発生することがあります。多分それはいくつかのコンパイルフラグによって有効にされていますか？

Ubuntu Lucid 10.04 PCで何かをコンパイルすると、glibcに対してリンクされます。Lucidは2.11のglibcを使用しています。古いglibcを搭載した別のPCでこのバイナリを実行すると、コマンドは失敗し、glibc2.11がないと表示されます...

私の知る限り、glibcはシンボルのバージョン管理を使用しています。gccを特定のシンボルバージョンに対してリンクさせることはできますか？

私の具体的な使用法では、ARM用のgccクロスツールチェーンをコンパイルしようとしています。

一部のライブラリ セットを無視するように valgrind に指示することは可能ですか? 具体的には glibc ライブラリ..

実際の問題: 通常の実行で正常に動作するコードがいくつかあります。漏れ等はありません。

valgrind で実行しようとすると、コア ダンプが発生し、プログラムが再起動/停止します。

コアは通常、glibc 関数 (通常は fseek、mutex など) を指します。互換性のない glibc / valgrind バージョンに問題がある可能性があることを理解しています。

さまざまな valgrind リリースと glibc バージョンを試しましたが、うまくいきませんでした。助言がありますか？