Segmentation Fault? (Loading image from another lua file)

Solar2D General Questions/Discussion
#1

I guess I’m posting to help others pretty often so hopefully someone can point out the (so obvious I’m missing it?) solution to this one.

The Error : “Segmentation Fault 11”, exit code 139 (OSX build 1005 and 982)
Basically, if I make more than one enemy using this code, Corona hard crashes and I get no information from it on possible code errors.

[code]-- enemy.lua
local M = {}
local options = {} – stuff is inside, sparing you the details
local enemyFrames = { 1, 2 } – enemy 1 has frame 1, enemy 2 has frame 2, easy peasy

function M.spawn(type)
local type = type or 1
local badguy = display.newImage( “sheet1.png”, enemyFrames[type])
return badguy
end
return M[/code]

This works just fine. Returns an enemy of whatever type I specified and it looks right.

[code]–main.lua
local enemy = require(“enemy”)

local monster1 = enemy.spawn(1)
local monster2 = enemy.spawn(2) – crashes on this line[/code]

Totally befuddled here. I’m not using any sort of complex metatable inheritance structure, so I must be making a fairly obvious mistake? [import]uid: 41884 topic_id: 35012 reply_id: 335012[/import]

#2

Hey, @richard9, I’m not sure, but what happens if you comment out the line [text]local type = type or 1[/text]? I believe the [text]type[/text] variable is localized with [text]function M.spawn(type)[/text] line, so you may also want to remove local from the line 7, i.e., do [text]type = type or 1[/text] instead…

Why do you need type to be type or 1 anyhow? Maybe that’s what’s making the function to break? Dunno. If you want the variable type to be 1 if/when no value is given, you may want to change the line to that effect, like so:
[text]if not type then type = 1 end[/text]

Just brainstorming…

Naomi [import]uid: 67217 topic_id: 35012 reply_id: 139195[/import]

#3

local type = type or 1 is simply a handy way to ensure that type is defined. It’s not clear whether type is already defined as local within the context of the function so I just redeclare it local to be safe.

Pretty sure this has been discussed in other threads, but or is actually faster (performance wise *and* typing wise) than using an if statement.So when making functions that require a table of options, it’s easier and faster to say options.unlock = options.unlock or true than to do an if statement to check for each one.

local function newGuy(options) local options = options or {} options.smug = options.smug or true options.hp = options.hp or 10 -- etc...these are all faster than doing if checks end

In any case, I started thinking about what you said and of course that led to my brain finding the typo; options{} defined Frame 1 twice instead of frame 1 and then 2. (Yay, the stupid typo has been found! Thanks Naomi! :slight_smile:

In terms of long-term troubleshooting hopefully Corona Labs can add an error or warning for trying to create an object to a non-existant frame. (I’ve seen the warning when using :setFrame(), but here it’s obviously not getting that far…) [import]uid: 41884 topic_id: 35012 reply_id: 139198[/import]

#4

Hey, @richard9, glad to hear you found the typo and fixed the issue. Great to learn about the use of or in place of if statement.

Cheers,
Naomi
[import]uid: 67217 topic_id: 35012 reply_id: 139202[/import]

#5

Glad you found it, but I would also discourage using “type” as a variable since it’s a built in function for returning the type of a variable. You were localizing it, so it shouldn’t be too damaging, but had it been done in global space, then all those functions that check the type would find a value with an integer in it and that would generate a SIGSEGV (a memory address that’s in protected memory, not user memory).
[import]uid: 199310 topic_id: 35012 reply_id: 139267[/import]

#6

Gotcha. I’m more worried about invalid frames just killing the app outright but I’ll try to steer clear of using protected words in localized functions. :wink: [import]uid: 41884 topic_id: 35012 reply_id: 139271[/import]

#7

Hey, @richard9, I’m not sure, but what happens if you comment out the line [text]local type = type or 1[/text]? I believe the [text]type[/text] variable is localized with [text]function M.spawn(type)[/text] line, so you may also want to remove local from the line 7, i.e., do [text]type = type or 1[/text] instead…

Why do you need type to be type or 1 anyhow? Maybe that’s what’s making the function to break? Dunno. If you want the variable type to be 1 if/when no value is given, you may want to change the line to that effect, like so:
[text]if not type then type = 1 end[/text]

Just brainstorming…

Naomi [import]uid: 67217 topic_id: 35012 reply_id: 139195[/import]

#8

local type = type or 1 is simply a handy way to ensure that type is defined. It’s not clear whether type is already defined as local within the context of the function so I just redeclare it local to be safe.

Pretty sure this has been discussed in other threads, but or is actually faster (performance wise *and* typing wise) than using an if statement.So when making functions that require a table of options, it’s easier and faster to say options.unlock = options.unlock or true than to do an if statement to check for each one.

local function newGuy(options) local options = options or {} options.smug = options.smug or true options.hp = options.hp or 10 -- etc...these are all faster than doing if checks end

In any case, I started thinking about what you said and of course that led to my brain finding the typo; options{} defined Frame 1 twice instead of frame 1 and then 2. (Yay, the stupid typo has been found! Thanks Naomi! :slight_smile:

In terms of long-term troubleshooting hopefully Corona Labs can add an error or warning for trying to create an object to a non-existant frame. (I’ve seen the warning when using :setFrame(), but here it’s obviously not getting that far…) [import]uid: 41884 topic_id: 35012 reply_id: 139198[/import]

#9

Hey, @richard9, glad to hear you found the typo and fixed the issue. Great to learn about the use of or in place of if statement.

Cheers,
Naomi
[import]uid: 67217 topic_id: 35012 reply_id: 139202[/import]

#10

Glad you found it, but I would also discourage using “type” as a variable since it’s a built in function for returning the type of a variable. You were localizing it, so it shouldn’t be too damaging, but had it been done in global space, then all those functions that check the type would find a value with an integer in it and that would generate a SIGSEGV (a memory address that’s in protected memory, not user memory).
[import]uid: 199310 topic_id: 35012 reply_id: 139267[/import]

#11

Gotcha. I’m more worried about invalid frames just killing the app outright but I’ll try to steer clear of using protected words in localized functions. :wink: [import]uid: 41884 topic_id: 35012 reply_id: 139271[/import]