Hatena::ブログ(Diary)

/* Grid Thinking */ このページをアンテナに追加 RSSフィード

2012-02-09 PlayStationVita の主な部品リスト このエントリーを含むブックマーク このエントリーのブックマークコメント

Sony CXD5315GG – Quad-core processor with two Samsung K4P2G324EC 256 MB Mobile DDR2-S4 SDRAM Memory die (512MB total memory)

Toshiba THGBM3G5D1FBAIE - Multichip Memory Package – Memory and Memory Controller

Marvell 88W878S-BKB2 - Avastar WLAN/Bluetooth/FM Single-Chip System-on-Chip

Fujitsu MB44C026A – Possible Multichannel Switching Controller

Sony 1144KM427 – suspected AKM Magnetic Compass

Wolfson Micro WM1803E – Audio Codec

Qualcomm MDM6200 – Gobi Single-mode Modem

Qualcom PM8028 – Power Management IC

Toshiba TY890A111222KA - Mobile SDR SDRAM Memory

Kionix KXTC9 - Three-axis MEMS accelerometer

Avago ACPM-7868 - GSM Power Amplifier

Avago ACPM-5005 - W-CDMA Band V Power Amplifier Module

Avago ACPM-5001 - W-CDMA Band I Power Amplifier Module

Avago ACPM-5002 - W-CDMA Band II Power Amplifier Module

Avago ACPM-5008 - W-CDMA Band VIII Power Amplifier Module

EPCOS B7429 - SAW Duplexer

Sony CXM3555ER - SP10T Antenna Switch Module

Atmel MXT224 – 224-Channel Touchscreen Sensor

STMicroelectronics 32P10SOD

STMicroelectronics 3GA51H - Gyroscope

B002X492PK
富士通
購入: 13人 クリック: 396回

2012-01-13 GDBでSegmentation Faultの原因を突き止める このエントリーを含むブックマーク このエントリーのブックマークコメント

 Linuxのプログラムをデバッグするとき、一番困ることはあの有名の「Segmentation Fault」ですね。
プログラムが膨大でマルチプロセス等を使っていたら、どこで問題を起こしているのかすらわからないです。
 本編はLinuxのCore Dump機能で問題発生行を特定する方法を紹介します。
 まず、前提としてはSegmentation Faultは再現できること。(当たり前ですよね)
 下記のプログラムを例とします。
#include<stdio.h>
#include<string.h>

#define DATA "TEST"

char            mngfile[2][50];

int main()
{
  memset( mngfile, '\0', sizeof(mngfile) );

  GetMngFile(mngfile);

  return 0;
}

int GetMngFile( mngfile )
  char            mngfile[2][50];
{
  int i=0;
  char    file[128];
  for(i=0;i<999;i++)
  {
    memset( file, '\0', sizeof(file) );

    strcpy(file,"abc");
    sprintf(mngfile[i],"%s_%s",file,DATA);
    printf("%d,%s\n",i,mngfile[i]);
  }
  return 0;
}
 次に、コンパイルオプションに「-g」を付けてコンパイルします。
  gcc test2.c -g -o test2
 多くのLinuxではデフォルトCoreDump機能を無効にしてあるため、有効にします。
  ulimit -c unlimited (生成するCoreのサイズを制限しない)
 プログラムを実行してみます。
  ./test2
  セグメンテーション違反です (core dumped)
 この時、カレントディレクトリで「core.11504」のようなファイルが生成されます。

 このCoreをGDBでデバッグしてみましょう。
  gdb ./test2 core.11504

  ・・・
  Core was generated by `./test2'. 
  (test2がCoreを吐いている)
  Program terminated with signal 11, Segmentation fault.
  (シグナル11でプログラムが終了され、セグメンテーション違反発生)
  Reading symbols from /lib/tls/libc.so.6...done.
  Loaded symbols for /lib/tls/libc.so.6
  Reading symbols from /lib/ld-linux.so.2...done.
  Loaded symbols for /lib/ld-linux.so.2
  #0  0x0058668b in _IO_default_xsputn_internal () from /lib/tls/libc.so.6 
  (最終実行ステップはlibc.so.6ライブラリの_IO_default_xsputn_internal()関数内にある)
(gdb)bt  (BackTraceしてみます。)
#0  0x0058668b in _IO_default_xsputn_internal () from /lib/tls/libc.so.6
#1  0x005645fa in vfprintf () from /lib/tls/libc.so.6
#2  0x0057c71b in vsprintf () from /lib/tls/libc.so.6
#3  0x0056995b in sprintf () from /lib/tls/libc.so.6
#4  0x080484ce in GetMngFile (mngfile=0x8049740) at test2.c:27
#5  0x08048441 in main () at test2.c:12
わたしのソースにのみ興味があるので、先頭にあるStack Frame番号の詳細をみます。
(gdb) frame 4
#4  0x080484ce in GetMngFile (mngfile=0x8049740) at test2.c:27
27          sprintf(mngfile[i],"%s_%s",file,DATA);

これでソースの27行目のsprintfで問題があることを判明しました。
このソースをよく見ると、配列mngfileの定義数を超えたメモリー領域のデータ改ざんのあったので、
これで問題判明です。

2010-05-25

知ってる人は知っているSQLPLUSの小技

1、put_lineの空白問題
set serveroutput on
exec dbms_output.put_line('   abc');
頭の空白を表示したいなら「format wrapped」オプションを使えばOK
set serveroutput on format wrapped
exec dbms_output.put_line('   abc');
2、空行エラー
このSQL文をコピーして実行してみてください。
select deptno, empno, ename
from emp

where empno = '7788';
すると、空行があるため下記のようにエラーになる
SQL> select deptno, empno, ename
  2  from emp
  3
SQL> where empno = '7788';
SP2-0734: unknown command beginning "where empn..." - rest of line ignored.
解決策として下記のコマンドを使う
SET SQLBLANKLINES ON
3、
こんな経験ないでしょうか?
SQL文を打ってる最中にカラム名が忘れて、
今まで打ったSQL文を消してカラム名を探す・・・
この場合「#」を利用すればOK
SQL> select
  2  #desc test
 Name                   Null?    Type
 ---------------------- -------- ------------
 ID                              NUMBER
 NAME                            VARCHAR2(30)

  2  name from test;

no rows selected
4、HTML出力
8iよりHTML出力が可能となった
set markup html on spool on
spool /tmp/test.html
select * from v$database;
spool off
5、前回SQL文の部分置換

SQL> select 'abc' from dual;

'AB
---
abc

SQL> c/'abc'/sysdate
  1* select sysdate from dual
SQL> /

SYSDATE
---------
25-MAY-10
6、前回SQL文の条件追加
SQL> select sysdate from dual;

SYSDATE
---------
25-MAY-10

SQL> a  where 1=2
  1* select sysdate from dual where 1=2
SQL> /

no rows selected
注意:コマンド「a」の後にスペース2個が必要です!!

2010-05-24

Oracle 11g のアンインストール

[oracle@CentOS53 ~]$ /u01/oracle/app/product/11.2.0/dbhome_1/deinstall/deinstall
Checking for required files and bootstrapping ...
Please wait ...
Location of logs /tmp/deinstall2010-05-24_11-13-21-午前/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############


######################## CHECK OPERATION START ########################
インストールの構成確認の開始


Oracleホームの場所が存在するかどうかを確認しています /u01/oracle/app/product/11.2.0/dbhome                                                                             _1
選択された削除対象のOracleホームのタイプ: SIDB
選択された削除対象のOracleベース: /u01/oracle/app
中央インベントリの場所が存在するかどうかを確認しています /u01/oracle/oraInventory

インストールの構成確認の終了


ネットワーク構成チェック構成START

ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/                                                                             netdc_check3056000027903696288.log

構成解除するすべての単一インスタンス・リスナーを指定してください[LISTENER1,LISTENER]:

ネットワーク構成チェック構成END

データベース・チェック構成START

データベース構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/                                                                             databasedc_check2296607471997779796.log

値のリストを入力として指定する場合、セパレータとしてカンマを使用してください

このOracleホームで構成されているデータベース名のリストを指定してください [o11g2]:

###### データベース'o11g2' ######

単一インスタンス・データベース
データベースの診断先の場所: /u01/oracle/app/diag/rdbms/o11g2
データベースによって使用される記憶域タイプ: FS
データベース・ファイルの場所: /u01/oracle/app/oradata/o11g2,/u01/oracle/app/flash_recovery                                                                             _area/o11g2
フラッシュ・リカバリ領域の場所: /u01/oracle/app/flash_recovery_area/O11G2
データベースのspfileの場所: /u01/oracle/app/product/11.2.0/dbhome_1/dbs/spfileo11g2.ora

データベースo11g2の詳細は自動的に検出されました。o11g2データベースの詳細を変更しますか。 [                                                                             n]: y


###### データベース'o11g2' ######

このデータベース(1.単一インスタンス・データベース|2.Oracle Restart対応のデータベース)のタ                                                                              イプを指定してください [1]:
データベースの診断先の場所を指定してください [/u01/oracle/app/diag/rdbms/o11g2]:
データベースASM|FSによって使用される記憶域タイプを指定してください [FS]:

共有ファイルシステムにデータベース・ファイルが存在する場合、ディレクトリのリストを指定して                                                                             ください。'o11g2'サブディレクトリが見つかった場合、これが削除されます。見つからなかった場                                                                              合、指定したディレクトリが削除されます。また、フルパスを使用してデータベース・ファイルのリ                                                                             ストを指定できます [/u01/oracle/app/oradata/o11g2,/u01/oracle/app/flash_recovery_area/o11g                                                                             2]:

フラッシュ・リカバリ領域がファイルシステムで構成されている場合、これを指定してください。'o                                                                             11g2'サブディレクトリが見つかった場合、これが削除されます。 [/u01/oracle/app/flash_recover                                                                             y_area/O11G2]:

データベースのspfileの場所を指定してください [/u01/oracle/app/product/11.2.0/dbhome_1/dbs/                                                                             spfileo11g2.ora]:

データベース・チェック構成END

Enterprise Manager Configuration Assistant START

EMCA構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/emcadc_c                                                                             heck.log

データベースo11g2の構成を確認しています
Enterprise Manager Configuration Assistant END
Oracle Configuration Manager check START
OCM check log file location : /tmp/deinstall2010-05-24_11-13-21-午前/logs//ocm_check9696.l                                                                             og
Oracle Configuration Manager check END

######################### CHECK OPERATION END #########################


####################### CHECK OPERATION SUMMARY #######################
選択された削除対象のOracleホーム: /u01/oracle/app/product/11.2.0/dbhome_1
Oracleホームが登録されているインベントリの場所: /u01/oracle/oraInventory
次の単一インスタンス・リスナーが構成解除されます: LISTENER1,LISTENER
次のデータベースが構成解除対象として選択されました: o11g2
一意のデータベース名: o11g2
使用済記憶域: FS
次のデータベースのEnterprise Managerの構成を更新しますか: o11g2
更新するEnterprise Manager ASMターゲットはありません
移行するEnterprise Managerのリスナー・ターゲットはありません
Checking the config status for CCR
Oracle Home exists with CCR directory, but CCR is not configured
CCR check is finished
続行しますか (y - はい、n - いいえ)[n]: y
このセッションのログは/tmp/deinstall2010-05-24_11-13-21-午前/logs/deinstall_deconfig2010-0                                                                             5-24_11-15-05-AM.outに書き込まれます
このセッションのすべてのエラー・メッセージは/tmp/deinstall2010-05-24_11-13-21-午前/logs/de                                                                             install_deconfig2010-05-24_11-15-05-AM.errに書き込まれます

######################## CLEAN OPERATION START ########################

Enterprise Manager Configuration Assistant START

EMCA構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/logs/emcadc_c                                                                             lean.log

データベースo11g2のEnterprise Manager Database Controlの構成の更新

Enterprise Manager ASMターゲットを更新しています(ある場合)
Enterprise Managerのリスナー・ターゲットを更新しています(ある場合)
Enterprise Manager Configuration Assistant END
データベース構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/
logs/databasedc_clean2778161591155929234.log
データベース・クリーンアップ構成START o11g2
この操作には数分かかります。
データベース・クリーンアップ構成END o11g2

ネットワーク構成クリーニング構成START

ネットワーク構成解除トレース・ファイルの場所: /tmp/deinstall2010-05-24_11-13-21-午前/
logs/netdc_clean2539645679609291858.log

単一インスタンス・リスナーの構成解除: LISTENER1,LISTENER

リスナーの構成解除: LISTENER1
    リスナーを停止しています: LISTENER1
    リスナーの停止に成功しました。
    リスナーを削除しています: LISTENER1
    リスナーは正常に削除されました。
リスナーは正常に構成解除されました。

リスナーの構成解除: LISTENER
    リスナーを停止しています: LISTENER
    警告: リスナーの停止に失敗しました。 リスナーが実行されていない可能性があります。
    リスナーを削除しています: LISTENER
    リスナーは正常に削除されました。
リスナーは正常に構成解除されました。

ネーミング・メソッド構成ファイルの構成解除中です...
ネーミング・メソッド構成ファイルが正常に構成解除されました。

ローカル・ネット・サービス名構成ファイルの構成解除中です...
ローカル・ネット・サービス名構成ファイルが正常に構成解除されました。

バックアップ・ファイルの構成解除中です...
バックアップ・ファイルが正常に構成解除されました。

ネットワーク構成が正常にクリーンアップされました。

ネットワーク構成クリーニング構成END

Oracle Configuration Manager clean START
OCM clean log file location : /tmp/deinstall2010-05-24_11-13-21-午前/logs/
/ocm_clean9696.log
Oracle Configuration Manager clean END
Oracle Universal Installerクリーンアップの開始

Oracleホーム'/u01/oracle/app/product/11.2.0/dbhome_1'をローカル・ノードの中央インベントリからデタッチします : 終了

ローカル・ノードのディレクトリ'/u01/oracle/app/product/11.2.0/dbhome_1'を削除します : 終了

ローカル・ノードのディレクトリ'/u01/oracle/oraInventory'を削除します : 終了

ローカル・ノード上でOracleベース・ディレクトリ'/u01/oracle/app'は削除されません。ディレクトリは空ではありません。

Oracle Universal Installerのクリーンアップが成功しました。

Oracle Universal Installerクリーンアップの終了


Oracleインストール・クリーンアップの開始

インストールのクリーンアップ操作により、ノードCentOS53の一時ディレクトリ/tmp/installを削除しています

Oracleインストール・クリーンアップの終了


######################### CLEAN OPERATION END #########################


####################### CLEAN OPERATION SUMMARY #######################
データベースo11g2のEnterprise Managerの構成を更新しました
次のデータベース・インスタンスが正常に構成解除されました: o11g2
次の単一インスタンス・リスナーが正常に構成解除されました: LISTENER1,LISTENER
Cleaning the config for CCR
As CCR is not configured, so skipping the cleaning of CCR configuration
CCR clean is finished
Oracleホーム'/u01/oracle/app/product/11.2.0/dbhome_1'がローカル・ノードの中央インベントリから正常にデタッチされました。
ローカル・ノードのディレクトリ'/u01/oracle/app/product/11.2.0/dbhome_1'が正常に削除されました。
ローカル・ノードのディレクトリ'/u01/oracle/oraInventory'が正常に削除されました。
Oracle Universal Installerのクリーンアップが成功しました。


セッション終了時にノード'CentOS53'でrootとして'rm -rf /etc/oraInst.loc'を実行します。

Oracleインストールにより、一時ディレクトリが正常にクリーンアップされました。
#######################################################################


############# ORACLE DEINSTALL & DECONFIG TOOL END #############

2010-03-05

CentOSでソースをRPMとしてインストールする方法

1、インストールしたいソースをダウンロードする
wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.gz

2、変換ソフトcheckinstallをインストールする
yum --enablerepo=rpmforge install checkinstall
* rpmforgeが見つからないエラー発生した場合:
(1)wget http://dag.wieers.com/rpm/packages/rpmforge-release/xxxxx.rpm
(2)sudo vi /etc/yum.repos.d/rpmforge.repo
enabled = 1
    ↓
enabled = 0


3、DLしたソースをコンパイルする
tar xvzf ruby-1.9.1-p0.tar.gz
cd ruby-1.9.1-p0
./configure --prefix=/usr
make

4、コンパイルしたソースをRPMへパッケージする
checkinstall --fstrans=no

5、準備完了したRPMをインストールする
rpm -ivh /usr/src/redhat/RPMS/i386/ruby-1.9.1-p0-1.i386.rpm