| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| BlockIP2 - SIGSEGV: address not mapped |
« View previous topic :: View next topic » |
| Author |
Message
|
| rastogianshul85 |
 Posted: Tue Aug 03, 2010 6:40 am Post subject: BlockIP2 - SIGSEGV: address not mapped |
 |
|
Newbie
Joined: 03 Aug 2010
Posts: 2
|
Hi All,
We have been using Blockip2 for quiet a long time, however recently we are
facing issue where a channel program amqrppa has to die because MQ sends a
SIGBUS signal fot it to die.
On further investigation, we found its on some channels loaded with Blockip2
Exit and it fails because BlockIp2 looks up a NULL memory segment.
FDC details :
Probe Id :- XC130003
SIGSEGV: address not mapped
Blockip2 Version Latest - 2.78
MQ version - 6.0.2.0
Also, this is not happening for other Qmgrs running on same Solaris 10 server.
I am trying to contact Joergen but his email is Out-Of-Quota.
Would be very helpful if I can get some guidance.
Regards,
AR |
|
| Back to top |
|
 |
| rastogianshul85 |
| Posted: Fri Aug 06, 2010 7:10 am Post subject: |
|
|
Newbie
Joined: 03 Aug 2010
Posts: 2
|
I did a lot of testing on BlockIP2 to trace down the actual Cause ..on why would UNIX sends SIGSEGV signal to amqrmppa incase channels are BlockIP2 enabled....
I would really appreciate if someone can pass it onto Joergen and other BlockIP2 developers....
Analysis
-- I have recereated scenorio many times.. with client connections using SVRCONN 5 times/seconds..( so its really sub-seconds connections )
-- Attached a truss program to amqrmppa process.
-- Below is truss output when channel dies due SIGSEGV..
-- It all happens while reading /var/mqm/mqs.ini..... file...
In Green, I am showing normal truss output when no issues.
/1192: open("/var/mqm/mqs.ini", O_RDONLY) = 12
/1192: fstat(12, 0xFFFFFFFF7A032900) = 0
/1192: fstat(12, 0xFFFFFFFF7A0327D0) = 0
/1192: ioctl(12, TCGETA, 0xFFFFFFFF7A03283C) Err#25 ENOTTY
/1192: read(12, " # * * * * * * * * * * *".., 8192) = 2396
/1192: read(12, 0x100115224, 8192) = 0
/1192: lseek(12, 0, SEEK_CUR) = 2396
/1192: close(12) = 0
In Red, is when crash happens..... mainly its the point where code perform fget on mqs.ini file to read all lines and copy them in memory buffer. and the address in Red-Bold is the culprit NULL pointer which is noted in FDC too.
/1193: open("/var/mqm/mqs.ini", O_RDONLY) = 13
/1193: fstat(13, 0xFFFFFFFF79F31EE0) = 0
/1193: fstat(13, 0xFFFFFFFF79F31DB0) = 0
/1193: ioctl(13, TCGETA, 0xFFFFFFFF79F31E1C) Err#25 ENOTTY
/ 1193: read(13, " # * * * * * * * * * * *".., 8192) = 2396
/1193: Incurred fault #6, FLTBOUNDS %pc = 0xFFFFFFFF7E101080
/1193: siginfo: SIGSEGV SEGV_MAPERR addr= 0xFFFFFFFF79F40000
/1193: Received signal #11, SIGSEGV [caught]
/1193: siginfo: SIGSEGV SEGV_MAPERR addr=0xFFFFFFFF79F40000
/1193: lwp_sigmask(SIG_SETMASK, 0x7E27F857, 0x0000FFF0) = 0xFFBFFEFF [0x0000FFFF]
/1193: getuid() = 33288 [33288]
/1193: stat("/var/mqm/errors/", 0xFFFFFFFF79F2FD30) = 0
/1193: getpid() = 15757 [24887]
/1193: open("/var/mqm/errors/AMQ15757.0.FDC", O_WRONLY|O_APPEND|O_CREAT|O_EXCL, 0640) = 14
/1193: fstat(14, 0xFFFFFFFF79F30868) = 0
/1193: lstat("/var/mqm/errors/AMQ15757.0.FDC", 0xFFFFFFFF79F30868) = 0
--------------------------------
Thanks |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Aug 06, 2010 8:21 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
I can't help you with BlockIP but I can tell you that any incorrect code (null pointer / accessing the wrong memory) will cause amqmppa to crash. It takes a lot of work and patience to get things to run smoothly in a security exit.
| Quote: |
| -- It all happens while reading /var/mqm/mqs.ini..... file... |
On a different note, many moons ago, on WMQ v5.3 for Solaris, I once had a very strange issue with a simple shell script that was used for monitoring. We used crontab to start the script every minute, to do some basic heart-beat monitoring. The first thing that the script did was to 'cat and while read line' against the mqs.ini file. The queue manager (only some queue managers) started getting very, very strange issues. i.e. puts taking a long time, some locks but I don't remember exactly what.
I spent weeks trying to figure it out. I even had a Unix SysAdmin running Unix monitoring tools to try to figure it out. After a lot of work, the Unix SysAdmin found that the 'cat and while read line' command was holding the mqs.ini at the same time as the queue manager was trying to access it. Hence, it caused all sorts of weird issues.
I change the script to copy the mqs.ini to the tmp directory and then all my problems went away. So, after many, many head banging hours, I learned my lesson. Don't fool around with the queue manager files.
Food for thought.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 14, 2011 2:56 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Is there a resolution to this BlockIP2 problem on Solaris? |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
