[tickets] [opensaf:tickets] #872 osafdtmd asserts after connect with non member node

2014-04-22 Thread Hans Feldt



---

** [tickets:#872] osafdtmd asserts after connect with non member node**

**Status:** unassigned
**Milestone:** future
**Created:** Wed Apr 23, 2014 06:45 AM UTC by Hans Feldt
**Last Updated:** Wed Apr 23, 2014 06:45 AM UTC
**Owner:** nobody

100% reproducible.

By mistake I had opensaf started on my native system (named xubuntu-13 below). 
Then I launched a virtual cluster which then keeps crashing. SC-1 in the 
virtual cluster stays up but all other nodes keeps crashing with the following 
assert:

Apr 23 08:35:27 SC-2 osafdtmd[352]: NO Established contact with 'xubuntu-13'
Apr 23 08:35:27 SC-2 osafdtmd[352]: dtm_node.c:108: dtm_process_node_info: 
Assertion '0' failed.

Apr 23 08:35:38 PL-3 osafdtmd[350]: NO Established contact with 'xubuntu-13'
Apr 23 08:35:38 PL-3 osafdtmd[350]: NO Established contact with 'SC-2'
Apr 23 08:35:38 PL-3 osafdtmd[350]: dtm_node.c:108: dtm_process_node_info: 
Assertion '0' failed.




---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #871 AMF: allow in-service modification of saAmfSGNumPrefActiveSUs for N+M service group

2014-04-22 Thread Alex Jones



---

** [tickets:#871] AMF: allow in-service modification of saAmfSGNumPrefActiveSUs 
for N+M service group**

**Status:** assigned
**Milestone:** future
**Created:** Tue Apr 22, 2014 09:39 PM UTC by Alex Jones
**Last Updated:** Tue Apr 22, 2014 09:39 PM UTC
**Owner:** Alex Jones

AMF does not currently allow saAmfSGNumPrefActiveSUs to be changed for an N+M 
SG while the SG is unlocked.

This prevents in-service capacity addition which really should be supported.

Let's say you have a 6-slot ATCA chassis, but you only want to use 3
slots at first in a 2+1 setup.  At some point in the future you want to
add more active capacity, but still keep it N+1.

Right now you would have to bring the SG down in order to add capacity,
which is not desirable.

This ticket proposes to allow saAmfSGNumPrefActiveSUs to be modified for an N+M 
SG while the SG is unlocked.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #870 AMF: syslog error escalation

2014-04-22 Thread Hans Feldt



---

** [tickets:#870] AMF: syslog error escalation**

**Status:** unassigned
**Milestone:** 4.5.FC
**Created:** Tue Apr 22, 2014 03:15 PM UTC by Hans Feldt
**Last Updated:** Tue Apr 22, 2014 03:15 PM UTC
**Owner:** nobody

Today AMF is rather silent when it does error escalation. For better 
understanding and troubleshooting it would be good to syslog all escalation 
decisions and why they are taken. Related timers should also be logged for 
example when they expire.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #861 IMMTOOLS: parsing default values in immcfg is not backward compatible

2014-04-22 Thread Zoran Milinkovic
- **status**: accepted --> review
- **Comment**:

http://sourceforge.net/p/opensaf/mailman/message/32255523/



---

** [tickets:#861] IMMTOOLS: parsing default values in immcfg is not backward 
compatible**

**Status:** review
**Milestone:** 4.4.1
**Created:** Thu Apr 17, 2014 08:39 AM UTC by Zoran Milinkovic
**Last Updated:** Thu Apr 17, 2014 08:39 AM UTC
**Owner:** Zoran Milinkovic

In ticket #20, improved parsing of values was added to immcfg, which detects an 
error in wrong written values and immcfg fails. It results in non-backward 
compatibility, and some earlier imported xml files cannot be imported now.

The ticket will revert the old way of working with additional printing of 
warnings to stderr if the wrong defined value exists in xml file. In this case, 
immcfg will not fail.

Also, a new flag --strict will be introduced, which means that immcfg will fail 
if it finds a wrong defined value in xml file. It is actually how immcfg works 
today. The flag will be applicable to -f and -L flags.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #868 AMF: object update continues despite it does not exist

2014-04-22 Thread Hans Feldt
- **status**: accepted --> review



---

** [tickets:#868] AMF: object update continues despite it does not exist**

**Status:** review
**Milestone:** future
**Created:** Tue Apr 22, 2014 01:21 PM UTC by Hans Feldt
**Last Updated:** Tue Apr 22, 2014 01:21 PM UTC
**Owner:** Hans Feldt

I think this is a typo or copy/paste error in ImmObjUpdate::exec:

if ((rc == SA_AIS_OK) || (rc == SA_AIS_ERR_EXIST)) {
delete Fifo::dequeue();
res = JOB_EXECUTED;

should probably say NOT_EXIST otherwise we end up in the default branch with 
logs like:

Apr 19 19:55:18 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:19  osafamfd[469]: last message repeated 4 times
Apr 19 19:55:19 SC-1 osafimmnd[409]: NO Ccb 7 COMMITTED (immcfg_SC-1_790)
Apr 19 19:55:19 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:19 SC-1 osafamfd[469]: ER Operation done, but invocationId for the 
operation on SI not found 'safSu=3,safSg=1,safApp=osaftest'
Apr 19 19:55:19 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:55  osafamfd[469]: last message repeated 11 times
Apr 19 19:57:16  osafamfd[469]: last message repeated 5 times



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #869 IMM: PBE must unlink any /tmp/imm.db.xxxx file when exiting on error

2014-04-22 Thread Anders Bjornerstedt
- Description has changed:

Diff:



--- old
+++ new
@@ -1,8 +1,6 @@
 If the PBE encounters a fatal problem during the creation of the temporary
 database file, then it should unlink that file before exiting. 
 
-If the PBE crashes it will still not do this, so it should do some cleanup
-at start/restart. Care needs to be taken on cleanup in 1PBE as race conditions 
-could arise between the two sides. But at least tmp files that are more than
-a few minutes old should be cleand up. For 2PBE all imm.db tmp files are 
-processor lcoal so all should be cleaned up.
+If the PBE crashes it will still not do this, so it should also cleanup
+at start/restart.  All imm.db tmp files are processor local, so it should
+be safe to remove all of them.






---

** [tickets:#869] IMM: PBE must unlink any /tmp/imm.db. file when exiting 
on error**

**Status:** unassigned
**Milestone:** future
**Created:** Tue Apr 22, 2014 01:55 PM UTC by Anders Bjornerstedt
**Last Updated:** Tue Apr 22, 2014 01:55 PM UTC
**Owner:** nobody

If the PBE encounters a fatal problem during the creation of the temporary
database file, then it should unlink that file before exiting. 

If the PBE crashes it will still not do this, so it should also cleanup
at start/restart.  All imm.db tmp files are processor local, so it should
be safe to remove all of them.



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #869 IMM: PBE must unlink any /tmp/imm.db.xxxx file when exiting on error

2014-04-22 Thread Anders Bjornerstedt



---

** [tickets:#869] IMM: PBE must unlink any /tmp/imm.db. file when exiting 
on error**

**Status:** unassigned
**Milestone:** future
**Created:** Tue Apr 22, 2014 01:55 PM UTC by Anders Bjornerstedt
**Last Updated:** Tue Apr 22, 2014 01:55 PM UTC
**Owner:** nobody

If the PBE encounters a fatal problem during the creation of the temporary
database file, then it should unlink that file before exiting. 

If the PBE crashes it will still not do this, so it should do some cleanup
at start/restart. Care needs to be taken on cleanup in 1PBE as race conditions 
could arise between the two sides. But at least tmp files that are more than
a few minutes old should be cleand up. For 2PBE all imm.db tmp files are 
processor lcoal so all should be cleaned up.



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #868 AMF: object update continues despite it does not exist

2014-04-22 Thread Hans Feldt



---

** [tickets:#868] AMF: object update continues despite it does not exist**

**Status:** accepted
**Milestone:** future
**Created:** Tue Apr 22, 2014 01:21 PM UTC by Hans Feldt
**Last Updated:** Tue Apr 22, 2014 01:21 PM UTC
**Owner:** Hans Feldt

I think this is a typo or copy/paste error in ImmObjUpdate::exec:

if ((rc == SA_AIS_OK) || (rc == SA_AIS_ERR_EXIST)) {
delete Fifo::dequeue();
res = JOB_EXECUTED;

should probably say NOT_EXIST otherwise we end up in the default branch with 
logs like:

Apr 19 19:55:18 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:19  osafamfd[469]: last message repeated 4 times
Apr 19 19:55:19 SC-1 osafimmnd[409]: NO Ccb 7 COMMITTED (immcfg_SC-1_790)
Apr 19 19:55:19 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:19 SC-1 osafamfd[469]: ER Operation done, but invocationId for the 
operation on SI not found 'safSu=3,safSg=1,safApp=osaftest'
Apr 19 19:55:19 SC-1 osafamfd[469]: ER exec: update FAILED 12
Apr 19 19:55:55  osafamfd[469]: last message repeated 11 times
Apr 19 19:57:16  osafamfd[469]: last message repeated 5 times



---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #771 logd crashed when logsv application is running

2014-04-22 Thread elunlen
- **status**: fixed --> accepted
- **Comment**:

Reopened.

Problem in the attribute validity check when creating and modifying log stream 
IMM objects. This may cause log to crash instead of returning an appropriate 
error message in some cases if attributes are set in an incorrect way when 
creating or modifying  IMM objects for streams. The current fix for #771 
handles one of the problems but there is more to fix.



---

** [tickets:#771] logd crashed when logsv application is running **

**Status:** accepted
**Milestone:** 4.5.FC
**Created:** Fri Feb 07, 2014 06:46 AM UTC by Sirisha Alla
**Last Updated:** Tue Apr 22, 2014 07:53 AM UTC
**Owner:** elunlen

The issue is seen on cs 4871 with patches #688, #711 and #721. After we have 
observed the issue we ran the same app on cs 4733 and we observed the same 
issue.

The backtrace of the crash is as follows:

Program terminated with signal 11, Segmentation fault.
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
1387lgs_imm.c: No such file or directory.
in lgs_imm.c
(gdb) bt
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
  #1  0x00411d48 in stream_ccb_apply (opdata=0x65cff0) at lgs_imm.c:1476
  #2  0x00411eea in ccbApplyCallback (immOiHandle=, 
ccbId=) at lgs_imm.c:1520
  #3  0x7effed26532a in imma_process_callback_info (cb=0x7effed4812e0, 
cl_node=0x653260, callback=0x65c8c0, immHandle=1718527) at imma_proc.c:2071
  #4  0x7effed267475 in imma_hdl_callbk_dispatch_all (cb=0x7effed4812e0, 
immHandle=1718527) at imma_proc.c:1688
  #5  0x7effed25870d in saImmOiDispatch (immOiHandle=1718527, 
dispatchFlags=SA_DISPATCH_ALL) at imma_oi_api.c:543
  #6  0x00412336 in main (argc=, argv=) 
at lgs_main.c:497
(gdb) thread apply all bt

Thread 5 (Thread 0x7effedad8b00 (LWP 3727)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6b36fd in osaf_ppoll (io_fds=0x7effedad81d0, i_nfds=1, 
i_timeout_ts=0x7effedad81a0, i_sigmask=) at osaf_poll.c:104
  #2  0x7effed6b38a7 in osaf_poll (io_fds=0x7effedad81d0, i_nfds=1, 
i_timeout=) at osaf_poll.c:43
  #3  0x7effed6b38f4 in osaf_poll_one_fd (i_fd=11, i_timeout=3) at 
osaf_poll.c:136
  #4  0x7effece16ff4 in rda_read_msg (sockfd=-307396144, msg=0x7effedad8250 
"", size=3) at rda_papi.c:662
  #5  0x7effece17970 in rda_callback_task (rda_callback_cb=0x630be0) at 
rda_papi.c:128
  #6  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #7  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #8  0x in ?? ()

Thread 4 (Thread 0x7effebc3f700 (LWP 3724)):
  #0  0x7effecc0461c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
  #1  0x0041d3b8 in file_hndl_thread (noparam=) at 
lgs_file.c:132
  #2  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #3  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #4  0x in ?? ()

Thread 3 (Thread 0x7effedaf8b00 (LWP 3726)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6eec6e in mdtm_process_recv_events () at mds_dt_tipc.c:580
  #2  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #3  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #4  0x in ?? ()

Thread 2 (Thread 0x7effedb28b00 (LWP 3725)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6b362a in osaf_poll_no_timeout (io_fds=0x7effedb28290, 
i_nfds=1) at osaf_poll.c:31
  #2  0x7effed6b3825 in osaf_ppoll (io_fds=0x7effedb28290, i_nfds=1, 
i_timeout_ts=0x, i_sigmask=0x) at osaf_poll.c:78
  #3  0x7effed6b9edf in ncs_tmr_wait () at sysf_tmr.c:411
  #4  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #5  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #6  0x in ?? ()

Thread 1 (Thread 0x7effedafb700 (LWP 3720)):
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
  #1  0x00411d48 in stream_ccb_apply (opdata=0x65cff0) at lgs_imm.c:1476
  #2  0x00411eea in ccbApplyCallback (immOiHandle=, 
ccbId=) at lgs_imm.c:1520
  #3  0x7effed26532a in imma_process_callback_info (cb=0x7effed4812e0, 
cl_node=0x653260, callback=0x65c8c0, immHandle=1718527) at imma_proc.c:2071
  #4  0x7effed267475 in imma_hdl_callbk_dispatch_all (cb=0x7effed4812e0, 
immHandle=1718527) at imma_proc.c:1688
  #5  0x7effed25870d in saImmOiDispatch (immOiHandle=1718527, 
dispatchFlags=SA_DISPATCH_ALL) at imma_oi_api.c:543
---Type  to continue, or q  to quit---
  #6  0x00412336 in main (argc=, argv=) 
at lgs_main.c:497
(gdb) fr 0
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
1387in lgs_imm.c
(gdb) p *opdata
$1 = {next = 0x0, userData = 0x0, userStatus = 0, operationType = 
CCBUTIL_MODIFY, objectName = {length = 43, 
value = "safLgStrCfg=appstream1,safApp=safLogService", '\000' }, ccbId

[tickets] [opensaf:tickets] #867 No clarity on assignments of dependents when sponsor has no CSIs

2014-04-22 Thread surender khetavath



---

** [tickets:#867] No clarity on assignments of dependents when sponsor has no 
CSIs**

**Status:** unassigned
**Milestone:** future
**Created:** Tue Apr 22, 2014 10:27 AM UTC by surender khetavath
**Last Updated:** Tue Apr 22, 2014 10:27 AM UTC
**Owner:** nobody

changeset : 5143
model : 2n

case:
1) configure any 2n model having 3sis
2) lock the SIs. create dependency SI1<-SI2<-SI3.
3) if there are any csis in SI1 delete them
4) unlock SI3/SI2/SI1 resp. 

As SI1 has no CSIs, it will be unassigned. And due to dependency dependents 
also remain unassigned. But the system is healthy i.e SUs,comps,sg everything 
is up and running. There is no log/document suggesting what should happen with 
assignments. 

It gives wrong perception, that system is healthy but no work load assigned. 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #866 IMM: Reduce spam from IMMND at loading

2014-04-22 Thread Anders Bjornerstedt



---

** [tickets:#866] IMM: Reduce spam from IMMND at loading**

**Status:** unassigned
**Milestone:** future
**Created:** Tue Apr 22, 2014 08:02 AM UTC by Anders Bjornerstedt
**Last Updated:** Tue Apr 22, 2014 08:02 AM UTC
**Owner:** nobody

The IMMND prints syslog messages of severity warning when loading anything
more than trivial ammounts of data. Both severity and frequency should be
reduced. Only ammounts approaching 300k objects should generate warning
messages. 


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #771 logd crashed when logsv application is running

2014-04-22 Thread elunlen
- **Comment**:

changeset:   5073:589b72d69877
parent:  5070:fc02663112d8
user:Lennart Lund 
date:Tue Mar 18 17:07:48 2014 +0100
summary: logsv: Do not allow NULL pointers for string variables in OI 
validity check [#771]

rev: 589b72d6987798cb52a615b98c8044a7157d3ce8

changeset:   5072:ce355da0165e
branch:  opensaf-4.4.x
parent:  5069:c03bf3b7eb6b
user:Lennart Lund 
date:Tue Mar 18 17:07:48 2014 +0100
summary: logsv: Do not allow NULL pointers for string variables in OI 
validity check [#771]

rev: ce355da0165e5cb93d8c58821aed3b2182580a7f

changeset:   5071:7b8ee8852e23
branch:  opensaf-4.3.x
parent:  5068:789d348c0819
user:Lennart Lund 
date:Tue Mar 18 17:03:21 2014 +0100
summary: logsv: Do not allow NULL pointers for string variables in OI 
validity check [#771]

rev: 7b8ee8852e23c3aa33b1a910f3c6735f4cd8ee82




---

** [tickets:#771] logd crashed when logsv application is running **

**Status:** fixed
**Milestone:** 4.5.FC
**Created:** Fri Feb 07, 2014 06:46 AM UTC by Sirisha Alla
**Last Updated:** Tue Mar 18, 2014 04:16 PM UTC
**Owner:** elunlen

The issue is seen on cs 4871 with patches #688, #711 and #721. After we have 
observed the issue we ran the same app on cs 4733 and we observed the same 
issue.

The backtrace of the crash is as follows:

Program terminated with signal 11, Segmentation fault.
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
1387lgs_imm.c: No such file or directory.
in lgs_imm.c
(gdb) bt
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
  #1  0x00411d48 in stream_ccb_apply (opdata=0x65cff0) at lgs_imm.c:1476
  #2  0x00411eea in ccbApplyCallback (immOiHandle=, 
ccbId=) at lgs_imm.c:1520
  #3  0x7effed26532a in imma_process_callback_info (cb=0x7effed4812e0, 
cl_node=0x653260, callback=0x65c8c0, immHandle=1718527) at imma_proc.c:2071
  #4  0x7effed267475 in imma_hdl_callbk_dispatch_all (cb=0x7effed4812e0, 
immHandle=1718527) at imma_proc.c:1688
  #5  0x7effed25870d in saImmOiDispatch (immOiHandle=1718527, 
dispatchFlags=SA_DISPATCH_ALL) at imma_oi_api.c:543
  #6  0x00412336 in main (argc=, argv=) 
at lgs_main.c:497
(gdb) thread apply all bt

Thread 5 (Thread 0x7effedad8b00 (LWP 3727)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6b36fd in osaf_ppoll (io_fds=0x7effedad81d0, i_nfds=1, 
i_timeout_ts=0x7effedad81a0, i_sigmask=) at osaf_poll.c:104
  #2  0x7effed6b38a7 in osaf_poll (io_fds=0x7effedad81d0, i_nfds=1, 
i_timeout=) at osaf_poll.c:43
  #3  0x7effed6b38f4 in osaf_poll_one_fd (i_fd=11, i_timeout=3) at 
osaf_poll.c:136
  #4  0x7effece16ff4 in rda_read_msg (sockfd=-307396144, msg=0x7effedad8250 
"", size=3) at rda_papi.c:662
  #5  0x7effece17970 in rda_callback_task (rda_callback_cb=0x630be0) at 
rda_papi.c:128
  #6  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #7  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #8  0x in ?? ()

Thread 4 (Thread 0x7effebc3f700 (LWP 3724)):
  #0  0x7effecc0461c in pthread_cond_wait@@GLIBC_2.3.2 () from 
/lib64/libpthread.so.0
  #1  0x0041d3b8 in file_hndl_thread (noparam=) at 
lgs_file.c:132
  #2  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #3  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #4  0x in ?? ()

Thread 3 (Thread 0x7effedaf8b00 (LWP 3726)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6eec6e in mdtm_process_recv_events () at mds_dt_tipc.c:580
  #2  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #3  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #4  0x in ?? ()

Thread 2 (Thread 0x7effedb28b00 (LWP 3725)):
  #0  0x7effec5464f6 in poll () from /lib64/libc.so.6
  #1  0x7effed6b362a in osaf_poll_no_timeout (io_fds=0x7effedb28290, 
i_nfds=1) at osaf_poll.c:31
  #2  0x7effed6b3825 in osaf_ppoll (io_fds=0x7effedb28290, i_nfds=1, 
i_timeout_ts=0x, i_sigmask=0x) at osaf_poll.c:78
  #3  0x7effed6b9edf in ncs_tmr_wait () at sysf_tmr.c:411
  #4  0x7effecc007b6 in start_thread () from /lib64/libpthread.so.0
  #5  0x7effec54f9cd in clone () from /lib64/libc.so.6
  #6  0x in ?? ()

Thread 1 (Thread 0x7effedafb700 (LWP 3720)):
  #0  stream_ccb_apply_modify (opdata=0x65cff0) at lgs_imm.c:1387
  #1  0x00411d48 in stream_ccb_apply (opdata=0x65cff0) at lgs_imm.c:1476
  #2  0x00411eea in ccbApplyCallback (immOiHandle=, 
ccbId=) at lgs_imm.c:1520
  #3  0x7effed26532a in imma_process_callback_info (cb=0x7effed4812e0, 
cl_node=0x653260, callback=0x65c8c0, immHandle=1718527) at imma_proc.c:2071
  #4  0x7effed267475 in imma_hdl_callbk_dispatch_all (cb=0x7effed4812e0, 
immHandle=1718527) at imma_proc.c:1688
  #5  0x7effed25870d in saImmOiDispatch (immO