# Seg fault reading jpeg in 9.2.2

**URL:** <https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337>\
**Category:** Development\
**Created:** [December 29, 2022, 6:27am UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337 "2022-12-29T06:27:40Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![efahl](https://discourse.vtk.org/user_avatar/discourse.vtk.org/efahl/32/1087_2.png) [@efahl](https://discourse.vtk.org/u/efahl)\
**Post date:** [December 29, 2022, 6:27am UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/1 "2022-12-29T06:27:40Z")

</div>

[jpg-bug.zip](https://discourse.vtk.org/uploads/short-url/xYLQcIchnYlVGDOkE9UnziqSxKp.zip) (2.2 KB)

I just was playing with Python 3.10.7, pip installed VTK 9.2.2 and ran one of our image reader tests. With VTK 9.1, when reading the bad one, `Samsung.jpg`, I’d see some error messages and get appropriate status, but with 9.2.2 I get a crash, `Segmentation fault`. I diffed vtkJPEGReader.cxx between the versions and nothing has changed there.

Attached zip contains a short script with three jpgs that read just fine, along with the offending one.

Here’s what I see in VTK 9.1. Can anyone confirm the seg fault in 9.2.2?

```auto
Samsung.jpg
2022-12-28 22:03:02.558 ( 0.211s) [] vtkJPEGReader.cxx:168 ERR| vtkJPEGReader (0000018D55A18F80): libjpeg could not read file: Samsung.jpg
2022-12-28 22:03:02.587 ( 0.241s) [] vtkJPEGReader.cxx:353 ERR| vtkJPEGReader (0000018D55A18F80): libjpeg could not read file: Samsung.jpg
2022-12-28 22:03:02.591 ( 0.244s) [] vtkExecutive.cxx:753 ERR| vtkCompositeDataPipeline (0000018D5274E420): Algorithm vtkJPEGReader(0000018D55A18F80) returned failure for request: vtkInformation (0000018D55C47D60)

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [December 29, 2022, 2:15pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/2 "2022-12-29T14:15:00Z")

</div>

I cannot reproduce on Linux with Python 3.10.8 with 9.2.2 or what is about to become 9.2.3.

---

<div class="post-metadata">

**Author:** ![efahl](https://discourse.vtk.org/user_avatar/discourse.vtk.org/efahl/32/1087_2.png) [@efahl](https://discourse.vtk.org/u/efahl)\
**Post date:** [December 29, 2022, 2:58pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/3 "2022-12-29T14:58:18Z")

</div>

Yeah, I missed OS, sorry. I tried a couple other configs, looks like it’s a Windows issue.

```auto
Ubuntu 20.04 Py 3.8 VTK 9.2.2 works
Win 10 Py 3.10 VTK 9.1 works
Win 10 Py 3.8 VTK 9.1 works

Win 10 Py 3.10 VTK 9.2.2 seg fault
Win 10 Py 3.8 VTK 9.2.2 seg fault

```

---

<div class="post-metadata">

**Author:** ![efahl](https://discourse.vtk.org/user_avatar/discourse.vtk.org/efahl/32/1087_2.png) [@efahl](https://discourse.vtk.org/u/efahl)\
**Post date:** [December 29, 2022, 3:34pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/4 "2022-12-29T15:34:01Z")

</div>

I’m building a debug version of 9.2.2 right now, maybe I can get a meaningful stack trace.

Oddly enough, the pointer reported as generating the seg fault changes between runs. I thought it was a null ptr at first, but then noticed it was non-null on a subsequent run, so started watching it and it appears to change each time. I also got the test to complete successfully once, apparently the stray pointer ended up pointing to user space, so it didn’t seg fault that time. Based on this, my initial guess is an uninitialized variable somewhere…

![image](https://discourse.vtk.org/uploads/default/original/2X/3/3c76541f5fa1a73f601af49726e2c02f99cb6120.png)

---

<div class="post-metadata">

**Author:** ![efahl](https://discourse.vtk.org/user_avatar/discourse.vtk.org/efahl/32/1087_2.png) [@efahl](https://discourse.vtk.org/u/efahl)\
**Post date:** [December 29, 2022, 4:23pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/5 "2022-12-29T16:23:59Z")

</div>

What’s the best way to dump this info from a Windows debug session? Pasting stuff copied from the debugger seems pretty unwieldy, I only rarely (maybe once a year) run Visual Studio so I’m completely unfamiliar with any of its capabilities wrt saving this in a form that someone else could grab and make use of…

Also, I couldn’t get VTK to build with `Debug`, so used `RelWithDebInfo` and non-debug Win10 Python 3.10.7.

```auto
Unhandled exception at 0x00007FFE0129A95B (vtkCommonCore-9.2.dll) in python.exe: 
0xC0000005: Access violation reading location 0x0000000000000030. occurred

```

```auto
|>|vtkCommonCore-9.2.dll!vtkOStrStreamWrapper::~vtkOStrStreamWrapper() Line 39|C++|
|---|---|---|
| |[External Code]||
| |vtkIOImage-9.2.dll!vtk_jpeg_error_exit(jpeg_common_struct * cinfo) Line 56|C++|
| |vtkjpeg-9.2.dll!get_dqt(jpeg_decompress_struct * cinfo) Line 559|C|
| |vtkjpeg-9.2.dll!read_markers(jpeg_decompress_struct * cinfo) Line 1049|C|
| |vtkjpeg-9.2.dll!consume_markers(jpeg_decompress_struct * cinfo) Line 325|C|
| |vtkjpeg-9.2.dll!vtkjpeg_jpeg_consume_input(jpeg_decompress_struct * cinfo) Line 313|C|
| |vtkjpeg-9.2.dll!vtkjpeg_jpeg_read_header(jpeg_decompress_struct * cinfo, unsigned char require_image) Line 263|C|
| |vtkIOImage-9.2.dll!vtkJPEGReader::ExecuteInformation() Line 200|C++|
| |vtkIOImage-9.2.dll!vtkImageReader2::RequestInformation(vtkInformation * __formal, vtkInformationVector * *__ formal, vtkInformationVector * outputVector) Line 468|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkImageAlgorithm::ProcessRequest(vtkInformation * request, vtkInformationVector * * inputVector, vtkInformationVector * outputVector) Line 100|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkExecutive::CallAlgorithm(vtkInformation * request, int direction, vtkInformationVector * * inInfo, vtkInformationVector * outInfo) Line 734|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkDemandDrivenPipeline::ExecuteInformation(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 452|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkStreamingDemandDrivenPipeline::ExecuteInformation(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 461|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 223|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation * request, vtkInformationVector * * inInfoVec, vtkInformationVector * outInfoVec) Line 369|C++|
| |vtkCommonExecutionModel-9.2.dll!vtkStreamingDemandDrivenPipeline::Update(int port, vtkInformationVector * requests) Line 386|C++|
| |vtkCommonExecutionModel.cp310-win_amd64.pyd!PyvtkAlgorithm_Update_s2(_object * self, _object * args) Line 2311|C++|
| |python310.dll!cfunction_call(_object * func, _object * args, _object * kwargs) Line 552|C|

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)\
**Post date:** [December 29, 2022, 8:45pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/6 "2022-12-29T20:45:58Z")

</div>

Seems to be a problem with libjpeg itself? I see that there is 2.1.4 available whereas VTK imports 2.1.0. I don’t see anything immediately important in the history of `jdmarker.c` (where `get_dqt` lives) though. Does a sanitizer build have any suggestions?

---

<div class="post-metadata">

**Author:** ![efahl](https://discourse.vtk.org/user_avatar/discourse.vtk.org/efahl/32/1087_2.png) [@efahl](https://discourse.vtk.org/u/efahl)\
**Post date:** [December 30, 2022, 12:39am UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/7 "2022-12-30T00:39:35Z")

</div>

I had not used the sanitizer, so looked at the CMake config. It appears to only support gcc and clang, but I’m using msvc, so processing `-D VTK_ENABLE_SANITIZER:BOOL=ON` reports:

```auto
CMake Warning:
  Manually-specified variables were not used by the project:
    VTK_ENABLE_SANITIZER

```

Is there something else I need to do, or just outta luck on Windows?

---

<div class="post-metadata">

**Author:** ![dgobbi](https://discourse.vtk.org/user_avatar/discourse.vtk.org/dgobbi/32/18_2.png) [@dgobbi](https://discourse.vtk.org/u/dgobbi)\
**Post date:** [December 31, 2022, 7:33pm UTC](https://discourse.vtk.org/t/seg-fault-reading-jpeg-in-9-2-2/10337/8 "2022-12-31T19:33:00Z")

</div>

From your stack trace, it looks like the crash occurs in the final line of the `vtkOStrStreamWrapper` because its `ostr` pointer has been corrupted:

```cpp
vtkOStrStreamWrapper::~vtkOStrStreamWrapper()
{
  if (!this->Frozen)
  {
    delete[] this->Result;
  }
  delete &this->ostr;
}

```

In `vtkJPEGReader`, the `vtkOStrStreamWrapper` is used via the `vtkErrorWithObjectMacro`. I believe the following block of code in `vtkJPEGReader::ExecuteInformation()` is executed via a `longjmp` from the libjpeg error handler:

```cpp
  if (setjmp(jerr.setjmp_buffer))
  {
    // clean up
    jpeg_destroy_decompress(&cinfo);
    // close the file
    if (jerr.fp)
    {
      fclose(jerr.fp);
      // this is not a valid jpeg file
      vtkErrorWithObjectMacro(this, "libjpeg could not read file: " << this->InternalFileName);
    }
    else
    {
      vtkErrorWithObjectMacro(this,
        "libjpeg could not read file from memory buffer: " << (this->MemoryBuffer ? "<ptr>"
                                                                                  : "(null)"));
    }
    return;
  }

```

Note that the `longjmp` unwinds the stack from `vtk_jpeg_error_exit()` back to the `setjmp()` in `vtkJPEGReader::ExecuteInformation()`, but this isn’t shown on the stack trace since a `longjmp` isn’t a function call.

Frankly, I can’t see how anything in libjpeg could be causing corruption of the `vtkOStrStreamWrapper` object, because all libjpeg calls are done before it is constructed. Seems more likely that the culprit is the `vtkOutputWindowDisplayErrorText` invocation in `vtkErrorWithObjectMacro`, since it is the only notable thing that occurs between the creation and destruction of the `vtkOStrStreamWrapper`.

However, if the segfault is related to `vtkOutputWindowDisplayErrorText`, then it should be popping up in more places than just `vtkJPEGReader`…