root 以外のアプリケーションは、使用できるすべてのスワップ空間を使用することがあり、その結果システムがハングアップしたり、重要なシステムデーモンが停止する場合があります。
回避方法: VM サブシステムは、物理的なメモリーの形で root プロセス用のスワップ空間を少量確保します。システム管理者は、ログインして、使用可能なスワップ空間をすべて使い果たしてエラーを引き起こしているユーザープロセスを停止できます。このため、システムのハングアップが防止され、重要なシステムデーモンの実行も保持されます。
root 以外のプロセスは、このプールに対しスワップ空間を確保できません。そのため df または swap -s コマンドが入力されると一部の root 以外のプロセスは利用できなくなり、利用できるスワップ空間がまだ少量残っていることを示すメッセージが表示されます。
アップグレードが必要なシステムに接続されたディスクでスライスが重複していると (バックアップスライスを除く)、アップグレードの設定処理が失敗します。ディスク領域の再割り当て機能を使用している場合は、自動配置処理が失敗します。
回避方法: format コマンドを使用して、重複したスライスを変更または削除します。
スライスを変更すると、変更されたスライスと、変更されたスライスに重複しているスライス上のデータは消失します。影響を受けるスライスのデータはすべて、スライス操作を行う前にバックアップを取ることをお勧めします。
cpr Suspend のあとでリブートすると、上記のメッセージがそのまま表示されるか、このメッセージの一部が変更されたものが表示されます。
cpr の使用基準を次に示します。
ルートは、ログ用のファイルシステムであってはなりません。
cpr ステートファイル (power.conf(4) のマニュアルページを参照) に選択されたファイルシステムは、ログ用のファイルシステムであってはなりません。
NFS プロトコルは、ファイルに対する変更、アクセス、およびメタデータ変更のあった時間を、1970 年 1 月 1 日からの経過秒数で数えた 32 ビットの符号なしの値として報告します。NFS では、理論上 2106 年まではこの報告が可能です。
Solaris 7 リリースでは、Solaris NFS クライアントおよびサーバーは、ファイルに対する負の時間を符号なしの値として誤って提示することはありません。したがって、以前の NFS プロトコル仕様に準拠した NFS クライアントは、最後に変更されたのが 1969 年であったファイルが実際には 2106 年に変更されたと解釈しました。
Solaris 7 リリースでは、NFS クライアントおよびサーバー実装は NFS プロトコルに完全準拠するように変更されました。NFS サーバーは、負の時間属性を持つファイルを処理する場合、NFS クライアントに対しファイルの属性の提供を拒否します。
したがって、負の時間属性を持つファイルは、NFS マウントではサポートされなくなります。NFS クライアントが負の時間属性を持つファイルにアクセスを試みると、クライアントは通常、「オーバーフロー」エラーを受けます。
tar アーカイブ、またはアーカイブに保管された負の時間属性を持つ cpio アーカイブを利用することもできます (tar(1) コマンド、cpio(1) のマニュアルページを参照)。NFS 上でこのアーカイブを抽出する場合、Solaris 7 NFS クライアントを使用するとアーカイブは動作しません。
回避方法: 最初の問題を解決するには、そのファイルが入った NFS サーバーにログインし (-m オプションを使用して起動された nfsstat(1M) ユーティリティがサーバーを識別する)、touch(1) コマンドを使用してファイルの時間を現在の日時に変更します。
既存の Motif バイナリのバイナリ互換性には影響ありません。Motif Application Programming Interface (API) の多くのパラメータは XmString 型で、オペーク型です。Motif API が XmString パラメタを期待している箇所で char* を使用している Motif ソースコードは、常に正しくありません。このような不正な Motif コードは、Solaris 7 オペレーティング環境でコンパイルされるとコアダンプしやすくなります。
回避方法: 古いバージョンの Motif を使用します。
システムの LC_TIME 環境変数が LC_MESSAGES 環境変数に設定されているものとは異なるロケールに設定されている場合、日付プロンプトは、Solaris CDE メールプログラムが期待するものとは異なる書式で表示されます。
回避方法: 不在通信メールを開始する前に、システムの LC_MESSAGES 環境変数と LC_TIME 環境変数が同じロケールに設定されていることを確認してください。
1、2、3、4 のようなヘブライ語およびアラビア語の文字や数字を含むテキストのコピーとペーストを行うと、それらの機能が正しく動作しません。
ヘブライ語またはアラビア語のロケールで dtmail を使用する場合、このどちらかの言語の名前を持つアタッチメントは、dtmail アタッチメントでその名前が左右逆方向に表示されます。
ヘブライ語またはアラビア語のロケールで dtcm を使用する場合、前面の「カレンダマネージャ」アイコン内の「月」の名前が左右逆方向に表示されます。
メッセージ本文に印刷不可能文字が含まれていると、dtmail が電子メールのメッセージ本文を切り捨てることがあります。
次の警告メッセージが表示されます。
「メッセージには、現在のロケールでは文字として不正なバイナリコードが含まれて います。このため、メッセージの一部が表示されない場合があります。このメッセージ が出力されているのと同じロケールで CDE を実行している場合は、メッセージ全体が 表示されます。」 |
電子メールのメッセージがあるロケールで作成され、その後別のロケールに送信される場合、電子メールの一部が切り詰められる場合があります。これは、メール内に受信側のロケールでは文字として無効なバイナリコードが含まれるためです。
このバグは、次のような場合に発生します。
電子メールが ko ロケールで作成され、ko_UTF.8 ロケールに送信される
電子メールが zh ロケールで作成され、zh.GBK ロケールに送信される
回避方法: 次の手順を実行します。
Solaris CDE を終了します。
メールが作成されたロケールで Solaris CDE にログインします。
または
dtmail を終了して環境変数 LANG を正しいロケールに設定し、その後 dtmail を再起動します。
同じデータがアタッチメントとして送信される場合には、表示上の切り捨ては発生しません。
dtmail を Solaris CDE でアラビア語ロケールを使用して開くと、アラビア語の日時の形状が正しく表示されず、その配置も正しく行われません。また、新しいメッセージダイアログにアラビア文字を挿入すると、アラビア文字の行に変わり、形状、配置ともに正しく表示されません。
ログイン画面で ar (アラビア語ロケール) を選択すると、dtlogin が非常に大きなフォントで表示されます。サインオン後のデフォルトフォントも、同様に大きくなります。
このバグは、Solaris 2.5.1 オペレーティングシステムでコンパイルされ、同時に XmText ウィジェットをサブクラス化するカスタム Motif ウィジェットが含まれる Motif プログラムにだけ影響を与えます。このようなプログラムは、Solaris 2.6 または Solaris 7 オペレーティングシステムで実行すると、コアダンプを起こす場合があります。
回避方法: Solaris 2.6、または Solaris 7 オペレーティングシステムでプログラムを再コンパイルします。
Solaris CDE で dtcm を選択すると、アラビア語のカレンダマネージャではどの予約も表示されません
回避方法: 次の手順を実行します。
dtlogin 画面で、ar (アラビア語ロケール) を選択します。
dtcm を起動し、アポイントエディタを開きます。
アラビア語テキストを含む新しい予約を追加します。
アポイントエディタを閉じます。
これで、新しい予約がカレンダマネージャに表示されます。
ユーザーがリモートの集中化サーバーからカレンダにアクセスするような集中化カレンダサービスを使用する場合、カレンダがスワップ空間で問題なく動作するにはカレンダファイルの 10 倍の容量がカレンダに必要です。
たとえば、ユーザーが同じサーバーからカレンダにアクセスしたい場合で、カレンダファイルの合計サイズが 50M バイトだと、カレンダが問題なく動作するのに 500M バイト必要です。
Solaris をインストールするときに上記の条件を考慮しないと、ユーザーがカレンダにアクセスするときに信頼性が低下する可能性があります。
回避方法: スワップ空間を増やして、カレンダが問題なく動作するようにします。
MWM を現在使用している場合は、Solaris CDE にアップグレードしてください。Solaris CDE は高度な機能を提供し、移行は難しくありません。MWM から完全な Solaris CDE に アップグレードできない場合、次の情報を参照してください。
Solaris 2.5 ソフトウェア開発者キットに含まれる Motif 開発キットを使用してアプリケーションを開発した場合、Solaris CDE に含まれるウィンドウマネージャ dtwm を使用できます。ウィンドウマネージャは MWM と同じように使用できます。また、ウィンドウマネージャは MWM 用のリソースファイルをサポートします。
次の設定により、dtwm フロントパネルを無効にできます。
Dtwm*useFrontPanel: False |
このリソースは .Xdefaults に設定できます。または、/usr/dt/app-defaults/C/Dtwm ファイルの既存のリソースを True から False に変更できます。
dtwm の -name オプションにより、既存の mwm リソースのほとんどを使用できます。-name オプションについては dtwm のマニュアルページを参照してください。
MWM カスタマは $HOME/.mwmrc ファイルに依存する場合と、依存しない場合があります。dtwm が $HOME/.mwmrc ファイルを読み取るように設定できる dtwm リソース config ファイルがありますが、リソースについては dtwm のマニュアルページで説明しています。
dtwm と mwm のルートメニューは異なります。dtwm ルートメニューはすべて構成可能です。ルートメニューでは任意の変更が可能です。詳細は、dtwm と dtwmrc のマニュアルページを参照してください。
Solaris CDE メールプログラムがメールボックスを開く場合、メールボックスの 2 倍の空きメモリーが必要です。たとえば、150M バイトのメールボックスがあると、メールボックスを開くのに最低 300M バイトの空きメモリーが必要です。
回避方法: スワップ空間を増やして、メールボックスを開きます。
スワップ空間が十分でない場合、Java アプリケーションでコアダンプが起き、次のバスエラーが表示されます。
not enough space |
回避方法: システムで動作しているほかのアプリケーションを終了するか、スワップ空間を追加します。スワップ空間の追加方法については『Solaris のシステム管理 (第 1 巻)』を参照してください。
Java Thread.suspend() メソッドにより Java のアプリケーションプログラムがハングすることがあります。suspend() および resume() メソッドを使用しないことをお勧めします。
ハングが起こる原因は、ロックを保持するスレッドが中断され、そのスレッドを再開するスレッドがこのロックを必要とするためです。これはスレッド化プログラミングの一般的な問題で、これらのプリミティブを正しく使用しないため、アプリケーションのデッドロックが発生します。
回避方法: wait() や notify() などの、他の同期メソッドを使用します。
java.sql.Timestamp は 2 けたの年表記を使用できますが、2000 年以降には対応できません (19XX の下 2 けたとして解釈するため)。4 けたの年を指定する場合には、この問題は起こりません。
java.sql.Timestamp クラスは、いくつかのメソッドが無効になっている java.util.Date クラスのサブクラスです。上位互換性を確保するには、 java.text.SimpleDateFormat メソッドを使用してください。
アプリケーションやサポートライブラリで、ランダムなバスエラーやセグメント例外が起きます。
回避方法: このようなプログラムは、java_g または java -debug を使用して実行するようにします。あるいは、次のコマンドで JIT を無効にすることもできます。
setenv JAVA_COMPILER NONE |
このどちらかの対策で、VM の実行プロファイルが変わります。
Java アプリケーションでの X 要求が多いと、8 ビットカラー (TrueColor または PseudoColor) 環境でときどき起動が遅くなります。処理速度の遅いマシン上では、より顕著にこの状態が現れます。起動が遅れる主な原因は、初期化時に awt ライブラリにより最適にディザ処理されるカラーマップの計算です。
回避方法: 初期化時に計算されたカラーマップの大きさを、環境変数 VIRTCUBESIZE を使用して調整します。4 から 32 までの間の 2 の累乗数を設定します。デフォルトは 32 です。
setenv VIRTCUBESIZE 8 |
-nojit を使用すると、次の警告が表示されます。
Warning: JIT compiler "none" not found. Will use interpreter |
回避方法: -Djava.compiler=NONE を設定します。
64 ビットの XViewTM または OLIT アプリケーションをコンパイルしようとすると次の警告メッセージが表示されます。
Creating 64-bit applications in {XView, OLIT} is not supported. |
仮想アドレス 0 (0x0) 〜 2G (0x80000000) で読み込まれた命令を実行する場合、特定の 64 ビットユーザーアプリケーションが停止するというバグがあります。システムは、ユーザープログラムがこのバグに遭遇しないように、自動的に 64 ビットアプリケーションがこの範囲の命令を読み込まないようにします。これにより、アプリケーションが使用できる物理的なメモリー量が減ったり、ユーザーデータがこの範囲で読み込まれなくなることはありません。このことは、32 ビットアプリケーションには影響しません。
ユーザーのマルチスレッドアプリケーションで _XRead が Xlib から実行される場合、そのアプリケーションはハングアップすることがあります。
回避方法: 次のいずれかを選択してください。
マルチスレッドを使用しない
または
Xlib ルーチンへのアクセスを、1 つのスレッドだけに制限する
フォト CD の I/O デバイスは、xil_get_pixel 操作をサポートしていません。
回避方法: フォト CD イメージの特定のピクセル値を取得する必要がある場合は、フォト CD イメージをメモリーイメージにコピーして、そのメモリーイメージ上で xil_get_pixel を呼び出します。
イメージビューア (sdtimage) は、画面でのイメージ操作中に特定の状況で停止する場合があります。この問題は、XIL が X Shared Memory (xshm) ディスプレイパイプラインを使用している場合にだけ起きます。XIL と xshm 間のこの問題は、スレッドのデッドロックが原因である可能性があります。
xshm パイプラインは、ワークステーションのフレームバッファに TCX や ZX フレームバッファのような高速 XIL ディスプレイドライバが存在しない場合だけ使用されます。 cg6(GX)、cg14(SX)、ffb(Creator)、および afb(Elite) フレームバッファの既存の高速 XIL ドライバはこの問題を起こしません。
回避方法:この問題が起きる場合は、sdtimage の代わりにイメージツール (/usr/openwin/bin/imagetool) を使用します。
XGL Gcache でエッジ付きの多角形を decomp 処理するとき、 xgl_gcache_multi_simple_polygon() で、いくつかのエッジが正しく描画されないことがあります。
回避方法: XGL_GCACHE_USE_APPL_GEOM を TRUE に設定してください。さらに、GCACHE コンテキストを作成するときには、xgl_gcache_multi_simple_polygon() のかわりに xgl_gcache_polygon() を使用して、XGL_GCACHE_SHOW_DECOMP_EDGES をオフにしてください。
サイズ変更要求をサーバーに送信する前にアプリケーションの resize_proc() を呼び出す XViewTM (おそらく他のツールキットも含めて) では、DGA から戻されたウィンドウのサイズがサイズ変更イベント 1 つ分だけ遅れています。
回避方法: xgl_window_raster_resize() を呼び出す前に XSync() を呼び出してください。
デフォルトの NSAPI サーバーではなく、CGI ベースの http サーバーを使用すると、 AnswerBook2 サーバーの管理アクセス認証が失敗します。
回避方法: 次の手順に従います。
文書サーバー上でスーパーユーザーになります。
次のコマンドを入力して、文書サーバー用の管理アクセス制御を無効にします。
# /usr/lib/ab2/bin/ab2admin -o access_off |
文書サーバーの管理機能へのアクセスについて制御する必要がある場合、http サーバー上で利用できるコマンドを使用して、次の URL へのアクセスを制限します。
/ab2/@Ab2Admin |
Compaq ProLiant 6500 の 3Com EtherLink III 3C905B カードは、割り込みに失敗する場合があります。このカードは、パケットの送信は行いますが受信は行いません。
回避方法: この問題を回避する方法は現在不明です。しかし、一部のスロットは他のスロットより頻繁にこの問題が起きていると思われるため、カードを他の PIC スロットに移すと改善される可能性があります。また、システムを複数回続けてリブートすると、解決することもあります。
一部の PCI マザーボードには、100-Mbps Fast Ethernet をサポートできない DMA チップセットが含まれます。
回避方法: 詳細と推奨される対策については、『Solaris 7 デバイスの構成 (Intel 版) 』の「100-Mbps Ethernet Performance」を参照してください。