The Glade 4.0
https://gladerebooted.net/

C Programming Question
https://gladerebooted.net/viewtopic.php?f=5&t=5460		 Page 1 of 1
Author:  Lex Luthor [ Wed Feb 09, 2011 11:29 pm ]
Post subject:  C Programming Question
I figured out that the following changes were necessary to stop the process from crashing. Does anyone know why? It's especially odd because in one build it works fine, but for another it leads to a runtime crash with a seg fault. The part that caused a segfault is &pool_info[loop_cnt] from right below. Maybe I'm just missing something obvious.

Code:
          rc = show_pool_brief_get_bag(svr_datalist,
                                               &pool_info[loop_cnt]);


Here's the relevant part of the diff:

Spoiler:
Code:
  uint32_t num_addrs_free = 0;
      uint32_t num_addrs_excl = 0;
      uint32_t num_addrs_total = 0;
!     ip_show_pool_brief pool_info[MAX_SHOW_POOLS];
 
      memset(&util, 0, sizeof(util));
 
      rc = show_sysdb_bind_server(&server_edm);
      if (CERR_IS_NOTOK(rc)) {
--- 271,280 ----
      uint32_t num_addrs_free = 0;
      uint32_t num_addrs_excl = 0;
      uint32_t num_addrs_total = 0;
!     ip_show_pool_brief *pool_info[MAX_SHOW_POOLS];
 
      memset(&util, 0, sizeof(util));
+     memset(&pool_info, 0, sizeof(pool_info));
 
      rc = show_sysdb_bind_server(&server_edm);
      if (CERR_IS_NOTOK(rc)) {
***************
*** 289,307 ****
      }
 
      for (loop_cnt = 0; loop_cnt < svr_bag_cnt; loop_cnt++) {
          rc = show_pool_brief_get_bag(svr_datalist,
!                                           &pool_info[loop_cnt]);
          if (CERR_IS_NOTOK(rc))
          {
              svr_bag_cnt = loop_cnt;
              break;
          }
!         num_addrs_alloc += pool_info[loop_cnt].num_addrs_alloc;
!         num_addrs_free += pool_info[loop_cnt].num_addrs_free;
!         num_addrs_excl += pool_info[loop_cnt].num_addrs_excl;
!         num_addrs_total += pool_info[loop_cnt].num_addrs_alloc +
!             pool_info[loop_cnt].num_addrs_excl +
!             pool_info[loop_cnt].num_addrs_free;
      }
      util.total_util_current = (num_addrs_alloc * 100) / num_addrs_total;
         
--- 290,314 ----
      }
 
      for (loop_cnt = 0; loop_cnt < svr_bag_cnt; loop_cnt++) {
+         pool_info[loop_cnt] = calloc(1, sizeof(ip_show_pool_brief));
+         if (!pool_info[loop_cnt]) {
+             printf("Could not allocate memory");
+             svr_bag_cnt = loop_cnt;
+             goto end;
+         }
          rc =  show_pool_brief_get_bag(svr_datalist,
!                                          pool_info[loop_cnt]);
          if (CERR_IS_NOTOK(rc))
          {
              svr_bag_cnt = loop_cnt;
              break;
          }
!         num_addrs_alloc += pool_info[loop_cnt]->num_addrs_alloc;
!         num_addrs_free += pool_info[loop_cnt]->num_addrs_free;
!         num_addrs_excl += pool_info[loop_cnt]->num_addrs_excl;
!         num_addrs_total += pool_info[loop_cnt]->num_addrs_alloc +
!             pool_info[loop_cnt]->num_addrs_excl +
!             pool_info[loop_cnt]->num_addrs_free;
      }
      util.total_util_current = (num_addrs_alloc * 100) / num_addrs_total;
Author:  Stathol [ Thu Feb 10, 2011 10:22 am ]
Post subject: 
It's hard to say, being unfamiliar with the code. What is the declaration for show_pool_brief_get_bag()?

In the first version of the code, you're passing it the address of pool_info[loop_cnt] (which is the same as pool_info + (loop_cnt * sizeof(pool_info[0])), if you think about it.) in the second, you're passing it the value pointed to by pool_info[loop_cnt]. What is the function expecting?
Author:  Lex Luthor [ Sun Feb 13, 2011 5:33 pm ]
Post subject:  Re:
Stathol wrote:
It's hard to say, being unfamiliar with the code. What is the declaration for show_pool_brief_get_bag()?

In the first version of the code, you're passing it the address of pool_info[loop_cnt] (which is the same as pool_info + (loop_cnt * sizeof(pool_info[0])), if you think about it.) in the second, you're passing it the value pointed to by pool_info[loop_cnt]. What is the function expecting?


Sorry for the late reply. show_pool_brief_get_bag() takes in the same types of argument that are passed to it. It compiles fine. It expects this type: ip_show_pool_brief *.I tried wiping out the function so that it simply returns upon entering, but it would still crash. It turned out the problem is not in show_pool_brief_get_bag().

I'm just going to consider the cause of this problem unsolveable :P. My fix worked though.
Author:  Rorinthas [ Tue Feb 15, 2011 9:51 am ]
Post subject: 
Welcome to the world of troubleshooting! Sometimes fixes just work and there is no good, logical, apparent, explanation for it.
Author:  Mookhow [ Tue Feb 15, 2011 5:47 pm ]
Post subject:  Re: C Programming Question
Once I was helping someone troubleshoot his C program. The program kept crashing when trying to manipulate a certain variable (divide by zero?). I added a print statement higher up in the code to verify the value of the variable before trying to manipulate it. The problem went away. I took out the printf(), and the problem came back. We ended up leaving an empty printf() statement in the code.
Author:  Lex Luthor [ Tue Feb 15, 2011 7:59 pm ]
Post subject:  Re: C Programming Question
Mookhow wrote:
Once I was helping someone troubleshoot his C program. The program kept crashing when trying to manipulate a certain variable (divide by zero?). I added a print statement higher up in the code to verify the value of the variable before trying to manipulate it. The problem went away. I took out the printf(), and the problem came back. We ended up leaving an empty printf() statement in the code.


That sounds like highly unstable code. :P It could break if you try to port it to another platform.
Author:  Stathol [ Tue Feb 15, 2011 11:55 pm ]
Post subject: 
http://en.wikipedia.org/wiki/Unusual_software_bug#Heisenbug
Author:  Timmit [ Wed Feb 16, 2011 10:33 am ]
Post subject: 
I used to maintain some fortran database code on an old Sperry Unisys mainframe that had an odd comment in the middle of one of it's subroutines that said only "Do not remove this comment or the program will break".

Of course, that's impossible, right? So we deleted the comment and suddenly it wouldn't compile...

We put the comment back and it compiled again. Computers are magical...
Author:  Lex Luthor [ Wed Feb 16, 2011 10:38 am ]
Post subject: 
I've been learning that while compilers and platforms seem to be dependable 99% of the time, they aren't perfect.
Page 1 of 1 All times are UTC - 6 hours [ DST ]
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/