-1

(I know using global variables isn't generally a good idea, but the way my lab is structured leads me to believe it's required.)

Basically I'm supposed to simulate a cache, and I've decided to make my cache an array of linked lists, where each node is a struct called "block" which contains information such as the address and a valid indicator.

In my original code, I had the (working) declaration:

struct block **cache = malloc(sizeof(struct block)*numofsets);

But since looking at the file I have to fit my cache-related functions into, I realized none of the functions that need to use the cache would have it in their scope, and I can't edit them, so I decided the only way to avoid this would be to increase the scope of my cache to become a global.

The main issue came when I put the declaration struct block **cache; outside of main, with *cache = malloc(sizeof(struct block)*numofsets); within the main. When I ran my code, it had a seg fault. I used print statements to find where the seg fault was coming from, and the malloc line is the culprit.

I'm not really sure how to fix this problem. Since I'm using C, I can't malloc the global outside of the main function since it give me an "initializer not constant" error, and fiddling with the pointers have gotten me worse errors. And what's more, this declaration/instantialization, to me, seems to be nearly identical in terms of structure to what it was before.

What is causing this instantialization to not work? Is there any way I can fix it, or is my implementation doomed?

Edit: I've been fooling around a little more with it, and I've realized the issue is not that it's a global variable, but that for some reason separating the declaration from the initialization gives me a seg fault. Not sure why this would be.

karleenamarx
  • 13
  • 3
  • 2
    Please post your code. But first, see [How to create a Minimal, Complete, and Verifiable Example](/help/mcve). – MD XF Dec 10 '16 at 23:35
  • Why are you using malloc? struct block *cache[numofsets] – Fredrik Dec 10 '16 at 23:59
  • "I used print statements to find where the seg fault was coming from": Try a debugger, it is actually easier, faster, more reliable, and tells you exactly where the problem is. If `malloc()` is really causing a segfault, you might have [heap corruption](http://stackoverflow.com/questions/22051294/malloc-segmentation-fault#answer-22052919) caused by code somewhere else. – e0k Dec 11 '16 at 00:00
  • Fredrik, I'm using malloc because numofsets gets so large that it causes a seg fault – karleenamarx Dec 11 '16 at 00:04
  • @Fredrik Maybe you don't know `numofsets` until run time, or you'd rather have it in the heap rather than on the stack. – e0k Dec 11 '16 at 00:04

1 Answers1

0
*cache = malloc(sizeof(struct block)*numofsets);

Putting * before cache, you're refering to the other pointer that cache is pointing to.

Correct code:

cache = malloc(sizeof(struct block)*numofsets);
UrbiJr
  • 133
  • 1
  • 2
  • 20
  • Oh, this is it! Thank you! – karleenamarx Dec 11 '16 at 00:06
  • No problem mate :-) – UrbiJr Dec 11 '16 at 00:07
  • P.S. Please check the answer as the solution to your question (I see that you're new here). – UrbiJr Dec 11 '16 at 00:09
  • I think this is a right way of thinking, but not exactly right. You want `cache` to point to an array of pointers, not an array of structs. What about `cache = malloc(sizeof(struct block *)*numofsets);`? But in general, don't use explicit types in a call to `malloc()`, let the compiler figure it out: `cache = malloc(sizeof(*cache)*numofsets);`. This means "allocate `numofsets` elements of whatever `cache` points to". Since `cache` is a `struct block **`, it points to a `struct block *`, not a `struct block`. – e0k Dec 11 '16 at 00:12
  • If this is your problem, the segfault is not from the `malloc()`, but from the dereference of `cache`, which happens to be on the same line. – e0k Dec 11 '16 at 00:14
  • Answer checked! Thanks, I was having trouble trying to figure out how to accept a solution. And than you to e0k for the expanded upon solution. – karleenamarx Dec 11 '16 at 05:45