Segmentation fault when calling eglMakeCurrent

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Segmentation fault when calling eglMakeCurrent

Jump to solution
9,388 Views
charlesung
Contributor III

We are using OpenVG with X11 on the imx6 and we encounter a problem that eglMakeCurrent will occasionally crash with segmentation fault. Not very sure on the cause. The input parameters seem to be valid at the time of the call. Below is the call stack when it dies.

 

 

==4346== Process terminating with default action of signal 11 (SIGSEGV)

==4346==  Access not within mapped region at address 0x394

==4346==    at 0x5E9DF64: gcoSURF_ReferenceSurface (gc_hal_user_surface.c:12505)

==4346==    by 0x5F90CC7: _CreateSurfaceObjects (gc_egl_surface.c:604)

==4346==    by 0x5F917CF: veglResizeSurface (gc_egl_surface.c:1389)

==4346==    by 0x5F8D34B: veglMakeCurrent (gc_egl_context.c:2508)

==4346==    by 0x5F8DD43: eglMakeCurrent (gc_egl_context.c:2633)

 

 

I have also attached the valgrind output that shows the steps that lead to this.

Original Attachment has been moved to: eglmakecurrent_bad.txt.zip

Labels (3)
1 Solution
7,492 Views
charlesung
Contributor III

This works. Thanks.

View solution in original post

0 Kudos
67 Replies
2,417 Views
sebastient
Contributor V

There is one surface per-window but only a single display and context.  You can have a number of surfaces (window or pixmap) to one context.  There is only a single thread.

0 Kudos
2,418 Views
charlesung
Contributor III

I don't think I understand your question on making many makeCurrent calls. The valgrind output that you saw was simply from a single eglMakeCurrent call, even though it flagged many places during the execution of that single call.

0 Kudos
2,418 Views
sebastient
Contributor V

That is a highly unlikely explanation to the Valgrind output.  These types of errors are generally a CBZ/CBNZ instructions on a register that was never loaded (uninitialized).  It is almost certainly a programming error.

When you say "better" do you mean required?  It will crash otherwise?  Also, is the requirement 16-byte aligned or bits?  Most of the hardware buffers on the i.MX6 require 16-byte alignment (for example the IPU).  Also claiming 8bits ok but 16bits better seems dubious, surely you'd at the very least require word alignment.  Especially considering 676 would be 16bits aligned, and any resolution would be 8bits aligned, any even number would be 16bit aligned.

0 Kudos
2,420 Views
charlesung
Contributor III

We tried destroying the old surface and recreating a new surface but it did not work somehow. But if you do have example showing us how to properly handle x11 window resize, that will be helpful.

Regarding your explanation on the error. If that is the case, wouldn't I see this issue any time I make the window size bigger? But I am not seeing that though.

0 Kudos
2,418 Views
chingling_wang
NXP Employee
NXP Employee

I think you need to do everything in deinit() and then init() to create window, surface etc

printf("Cleaning up...\n");

eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);

assert(eglGetError() == EGL_SUCCESS);

eglDestroyContext(egldisplay, eglcontext);

eglDestroySurface(egldisplay, eglsurface);

fsl_destroywindow(eglNativeWindow, eglNativeDisplayType);

eglTerminate(egldisplay);

assert(eglGetError() == EGL_SUCCESS);

eglReleaseThread();

0 Kudos
2,418 Views
charlesung
Contributor III

Please do not tell me I have to destroy and recreate the actual X window any time I resize it.

2,418 Views
chingling_wang
NXP Employee
NXP Employee

X window resize is done by x window manager, not by egl. you don't need to close it..  egl just need to know the window hander when created egl window.  Yes, you can keep the same window hwd, but, you need to call x11 api like XResizeWIndow() whatever to change your window dimension.  after resizing, still pass the same hwd to egl

0 Kudos
2,418 Views
charlesung
Contributor III

I thought you said we need to do what were in init and deinit which include destroying and creating the native window. Otherwise, we are simply destroying and recreating the egl surface and we have tried that with no succeed.

0 Kudos
2,418 Views
chingling_wang
NXP Employee
NXP Employee

But. I think you need to do

eglMakeCurrent(egldisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);

    assert(eglGetError() == EGL_SUCCESS);

    eglDestroyContext(egldisplay, eglcontext);

    eglDestroySurface(egldisplay, eglsurface);

Then using the current hwd to XResizeWIndow(),  let window manager resize the window.

then

eglCreateWIndowSurface()

eglCreateContext()

eglMakeCurrent()

Anyway, I am writing a simple openvg to resize the window.

0 Kudos
2,418 Views
sebastient
Contributor V

Requiring destruction of the context on resize is not reasonable, could you please confirm that this is in fact required? 

0 Kudos
2,418 Views
charlesung
Contributor III

Do you mind explaining to us what veglResizeSurface in gc_egl_surface.c line 1440 is doing or suppose to do before you spend your time on your vg example?

0 Kudos
2,418 Views
chingling_wang
NXP Employee
NXP Employee
0 Kudos
2,418 Views
charlesung
Contributor III

We were hoping that the valgrind output leaves enough bread crumbs along the path that someone with the source code will be able to figure out where it took a wrong turn if indeed it did.

0 Kudos
2,418 Views
charlesung
Contributor III

I guess you are assuming the app is triggering the window size change but it may not be the case. The size change can come from X11 through the GUI input.

0 Kudos
2,420 Views
sebastient
Contributor V
  1. Yes, it is a rect of x,y,w,h.  Otherwise it is not clear what the question is?  This is an X11 surface, a window could be anywhere on the screen.
  2. 1280 is 16-byte aligned, any value for height will therefore also be 16-byte aligned.
  3. The issue is not on setup, it's really while handling window resize that the issue is seen.
  4. Have you looked at the Valgrind output which points to conditional branches on uninitialized variables within the driver?
0 Kudos
2,420 Views
charlesung
Contributor III

I copied most of the .so files in gpu-core folder that are relevant to my target and the problem still exists. The valgrind looks almost identical with slight difference in some line numbers but that is about it. I have attached the valgrind output that shows the steps that lead to the seg fault after it enters the eglMakeCurrent function. The output is captured with the new gpu driver in place.

0 Kudos
2,420 Views
chingling_wang
NXP Employee
NXP Employee

I transweb the file to you.  It is too large to be attached

0 Kudos
2,420 Views
charlesung
Contributor III

Run into an error during unpacking. Any idea?

Do you accept the EULA you just read? (y/N) y
EULA has been accepted. The files will be unpacked at 'imx-gpu-viv-5.0.11.p8.4-hfp'

Unpacking file .......................................................................................................................................................................................................................................................................................................................................................................................................................................ERROR:
.Signal caught, cleaning up

0 Kudos
2,419 Views
chingling_wang
NXP Employee
NXP Employee

yes, y.

I can get it without any problem.

I will pack it for you.  I replaced it , It seems it passed the eglMakeCurrent(0 without seg fault.  But, I got some error of undefined symblol in lib you sent.

0 Kudos
2,419 Views
charlesung
Contributor III

The gpu driver being used should be p8.3 based on the yocto content.

0 Kudos
2,420 Views
chingling_wang
NXP Employee
NXP Employee

you can get p8.4 in external mirror 

http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/imx-gpu-viv-5.0.11.p8.4-hfp.bin

You may try is gpu driver first to see if it can fix your problem

0 Kudos