CarbonWolf / aff4

Automatically exported from code.google.com/p/aff4
GNU General Public License v3.0
0 stars 0 forks source link

error notification issue in lib/ewfvolume.c #2

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
lib/ewfvolume.c line 192:
RaiseError(ERuntimeError, "libewf error: %s", ewf_error);

I think this will cause a problem because ewf_error is of type libewf_error_t 
which is not a string, but an error 'object'.

Use libewf_error_sprint() or libewf_error_backtrace_sprint() to copy the error 
to a C char string first.

Joachim

Original issue reported on code.google.com by joachim.metz@gmail.com on 17 Aug 2010 at 4:53

GoogleCodeExporter commented 8 years ago
Also I'm not sure if defining ewf_error 
'static libewf_error_t *ewf_error;'
provides the desired result of not having to free ewf_error.

The actual error 'object' is created on the heap by malloc. I think the static 
solution leaks memory and ewf_error should be freed by calling 
libewf_error_free instead.

For my part I'll work on some documentation describing the usage of ewf_error 
for version 2. 

Original comment by joachim.metz@gmail.com on 17 Aug 2010 at 5:01

GoogleCodeExporter commented 8 years ago
Joachim,
  Do you mean that every call to the library returns a new ewf_error object which is allocated by the function? or is a new object only allocated if an error occurs?

Mic

Original comment by scude...@gmail.com on 19 Aug 2010 at 9:14

GoogleCodeExporter commented 8 years ago
The error object is only newly allocated if error contains NULL, in C if:
(*error == NULL); otherwise an error string is added, building up a back-trace.

If error itself is NULL no error object is created at all.

Original comment by joachim.metz@gmail.com on 19 Aug 2010 at 10:17

GoogleCodeExporter commented 8 years ago
I have committed a possible fix. Please let me know if this looks right.

Original comment by scude...@gmail.com on 19 Aug 2010 at 11:00

GoogleCodeExporter commented 8 years ago
They look quite right. Your changes fixes the issue passing the error object as 
a string and the error object for the EWFVolume_load_from function.

However there two more locations which the error object is used. I attached a 
patch with a clean up of these 2 as well.

I also changed the check for libewf_handle_open. It checks if the return value 
is 0, but it should check for either -1 on error or 1 for success. 

Original comment by joachim.metz@gmail.com on 20 Aug 2010 at 8:49

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by scude...@gmail.com on 20 Aug 2010 at 9:36