cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Methylene
Journeyman III

Mapping a kernel twice fails...

So in my little terrain demo, I was trying to implement a simple method to shift the coordinates of the input so as to render different portions of the terrain map by simply pressing a button in the direction I'd like to shift it.

The problem is mapping the kernel again.  No matter what it always crashes with a segmentation fault, it seems one for each of the arguments to the kernel.

This is how it goes down.

Initialize opengl, sdl, etc...

Run kernel outputting to a buffer in system memory, map the vertices and extrapolate color values into 2 VBOs.
Generate indices.

free(heightmap)

heightmap = NULL;

Rendering now occurs peachy keen!

*Press button to shift the height map coordinates*

Reallocates the input and output buffers.

Prepares input buffer coordinates.

Enters the kernel again and attempts the map function.

Gets as far as... brook::CALContext:rawRectangle() calcontext.cpp:1243 0x00007f0e72792f92   

Reports SIGSEGV / Symbol(s) not available:

13 0x00007f08366036f0   
12 0x00007f083660440d   
11 0x00007f0836604d3c   
10 0x00007f08365fd43a

CRASH!

 

Any ideas?  Feel free to request more info on the problem I don't have a clue how to fix it as I've assured the pointers are all freed/NULL/reallocated as necessary, and it just seems the kernel is not recognizing the new memory locations for any of the input variables.


APPENDED:

I just had the bright idea to try running the streamread/kernel/streamwrite commands twice in a row in order to determine when this problem crops up...

It actually only occurs once the function encompassing the brook kernel execution exits.   This function allocates the input buffer, it used to allocate the output buffer but it only really needs to be done once for my current experiments, so I left it static.  Now I've even insured that no buffer is initialized twice, and hence the input/ouput buffer pointers are essentially static locations in memory.  It still doesn't work, and the opposite scenario of freeing the buffers and reallocating them is not working either.

So the issue seems to stand that upon exiting the function the first time

After essentially stripping it down and adding conditional statements to the function, I've made it so it essentially just calls streamread/kernel/streamwrite.

So whatever happens once the streams go out of scope must be the issue here.

0 Likes
9 Replies
Methylene
Journeyman III

I'm bad with quick hexidecimal approximations and such, but this is the culprit for the missing symbols isn't it?

Type: shared library
Symbols: loaded
Symbols file: /usr/lib/libamdcalrt.so
Base address: 0x00007f69a1df0040
Size: 2794424

13 0x00007f69a1f2d6f0   
12 0x00007f69a1f2e40d   
11 0x00007f69a1f2ed3c   
10 0x00007f69a1f2743a   

EDIT:

gCalcTool says...

7f69a1f2743a-7f69a1df0040 = 1373FA = 1274874

I'd like to reask the recent question, where can I find say an amd64 binary for 1.2.0 or 1.1.0 to do some regression testing?

FURTHER:

Assertion failure: calcontext.cpp (1251): Could not run program.

BrookTerrain: calbase.hpp:92: void CALAssertImpl(const char*, int, const char*): Assertion `0' failed.

if I just run the function which executes the kernel twice in a row, I get this.

If I use my button to make the function run again, I just get the usual segmentation fault.

0 Likes

First of all i have the two bugs also.

Like:

Assertion failure: calcontext.cpp (1251): Could not run program.

prod_5: calbase.hpp:92: void CALAssertImpl(const char*, int, const char*): Assertion `0' failed.

_OR_ Seg fault

When I calling a kernel more then once..... or using .execDomain(1)

seems like this bug is also not catched =/

http://forums.amd.com/forum/messageview.cfm?catid=328&threadid=99991&highlight_key=y&keyword1=segmentation%20fault

Has anybody an idea to solve the problem?

 

-----
SDK 1.2.1, Ubuntu Server 8.04 64bit, ati 4870

0 Likes

Well although the problem may be similiar, removing the integer constant or making it into a stream of  length equal to the input stream does not fix the problem.

if I do say...

for(i=0;i<100;i++)
    GenerateHeightMap(inputStream,outputStream,seed);

(calling the kernel 100x in a row)

it does not crash.  However like I said as soon as the function this is in ends, and it is attempted to be called again, it crashes upon entering the kernel.

EDIT:

I'd also like to note that I was looking to invest in a 4870 with 1 gig of vram, however I cannot and will not waste my time until this bug is fixed, as it has stopped my work.  I will need to call this kernel over and over to generate new values for my future caching/LOD algorithm, each call will likely have different size streams(constrained to what is supported by my card for a single pass).

The sooner this is resolved, the sooner I will consider getting a new card (as I would just love to be able to generate some 4096^2+ coordinates per pass, and be able to render much more than I can now.

0 Likes

If the streams are declared in the beginning of the function I can call my kernel until the streams go out of scope... (I can't call the function twice but I can run the kernel as many times as I want).

If I declare the streams as global, as soon as the function goes out of scope I still cannot call the kernel again.

If I leave the streams in their own scope where I call the kernel, I can call the kernel until the streams go out of scope....

Very strange...  It's as if the streams going out of scope causes the problem, yet globalizing them will not fix the problem....

0 Likes

Originally posted by: Methylene

If the streams are declared in the beginning of the function I can call my kernel until the streams go out of scope... (I can't call the function twice but I can run the kernel as many times as I want).

If I leave the streams in their own scope where I call the kernel, I can call the kernel until the streams go out of scope....


Can you plz give an example, how do you mean this?

0 Likes

Methylene, This is a known issue and is being fixed for the next major release.
0 Likes

Thank you very much for the response.  Did you talk to Micheal Chu at all?  We were wondering if this has been an issue from the start or not, or what version I can regress to in order to get around it.

0 Likes

Yeah a generally Buglist or a Fixlist would be very nice and would make work much easier...

0 Likes

I confirmed that the regression happened going from 1.1 to 1.2.

I also confirmed that, on the internal 1.3 release candidate that this is fixed as well.

Sorry for the testing hole everyone! We'll get this in our testing suite for next time!

Michael.
0 Likes