==18373== Conditional jump or move depends on uninitialised value(s)
==18373== at 0x825CC9B: CtrlMemView::render(wxDC&) (CtrlMemView.cpp:277)
==18373== by 0x825DA19: CtrlMemView::paintEvent(wxPaintEvent&) (CtrlMemView.cpp:138)
==18373== by 0x81F3A5F: Pcsx2App::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) (AppMain.cpp:614)
==18373== by 0x40BC50B: wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==18373== by 0x426C654: wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==18373== by 0x426C752: wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
Reported by gcc too
Fix valgrind issue:
==3560== Conditional jump or move depends on uninitialised value(s)
==3560== at 0x81F7949: CtrlRegisterList::OnDraw(wxDC&) (CtrlRegisterList.cpp:291)
==3560== by 0x47826DE: wxAnyScrollHelperBase::HandleOnPaint(wxPaintEvent&) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x4785969: wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x426CA0E: wxEvtHandler::SafelyProcessEvent(wxEvent&) (in /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0.2.0)
==3560== by 0x4710BAE: wxWindowBase::HandleWindowEvent(wxEvent&) const (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
==3560== by 0x44EF67D: wxWindow::GTKSendPaintEvents(_GdkRegion const*) (in /usr/lib/i386-linux-gnu/libwx_gtk2u_core-3.0.so.0.2.0)
Use portaudio devel build for devel config - it fixes a warning that
occurs due to incompatible linker settings (incremental vs whole program
optimisation)
Also add 64-bit configurations.
I'm not sure to understand why Valgrind reports it as we populate the buffer
during the ReadAsync. Maybe Valgrind doesn't like async IO from the kernel.
In doubt, the init will avoid those warnings
==19897== Thread 6 EE Core:
==19897== Conditional jump or move depends on uninitialised value(s)
==19897== at 0x80FE9E1: BlockdumpFileReader::DetectBlockdump(AsyncFileReader*) (BlockdumpFileReader.cpp:40)
==19897== by 0x8109EE5: InputIsoFile::Open(wxString const&, bool) (InputIsoFile.cpp:229)
==19897== by 0x810939E: ISOopen(char const*) (CDVDisoReader.cpp:57)
==19897== by 0x810194E: DoCDVDopen() (CDVDaccess.cpp:359)
==19897== by 0x80B651C: SysCorePlugins::OpenPlugin_CDVD() (PluginManager.cpp:1219)
It is a pseudo leak as it is a global object. Nevertheless it pollutes
the valgrind log.
v2:
* use an array of unique pointer
* use ArraySize instead of a constant
Group common properties. This removes some of the optimisation
properties, which aren't really essential since bin2cpp is only used as
a tool to convert images to header files.
Add 64-bit configurations.
Combine all the different configurations together so the project files
are more generic and maintainable.
Also standardise the layout so all the project files will be similar and
all have the same standard elements (even if empty).
Add 64-bit configurations.
Additional specifics:
spu2-x: FLOAT_SAMPLES preprocessor definition removed since it's unused.
Combine all the different configurations together so the project files
are more generic and maintainable.
Also standardise the layout so all the project files will be similar and
all have the same standard elements (even if empty).
Add 64-bit configurations.
Combine all the different configurations together so the project files
are more generic and maintainable.
Also standardise the layout so all the project files will be similar and
all have the same standard elements (even if empty).
Add 64-bit configurations.
Additional specifics:
wxWidgets: Common stuff into the property sheets.
pthreads: Fixes the LNK4068 warning.
portaudio: Devel config added.
libjpeg: Non-existent file removed.
Side note: libjpeg is barely used - wxWidgets uses it but doesn't have
to, ZeroGS uses it but we don't develop that anymore.
Don't use "-dbg" target suffix - both Devel and Debug builds use the
property sheet, so it's incorrect.
Also don't set optimise references to false - it's incompatible with
incremental linking and causes compile failures.
Write pointer can be relaxed-read from the EE thread
Read pointer can be relaxed-read from the VU thread
Warning: AtomicExchange calls were replaced by release-store
However AtomicExchange generates a memory barrier (at least on linux)
So either it is useless and it will be faster, or it will explode ;)
* Avoid the generation of memory barrier (mfence)
* Based on the fact that it used to work on previous code without any
barrier
v2:
* keep basic code in reset path
* use relaxed access for isBusy. The variable doesn't carry load/store
dependency but is instead an hint to optimize semaphore post
Read pointer is only written by the MTGS thread so it can be relaxed-read
by the MTGS thread
Write pointer is only written by the EE thread so it can be relaxed-read
by the EE thread
Remove volatile stuff
* Avoid the generation of memory barrier (mfence)
* Based on the fact that it used to work on previous code without any
barrier
v2:
* keep "slow" and safe atomic on reset path
* use relaxed atomic for m_RingBufferIsBusy
The signal doesn't carry dependency with others load/store. Instead it is used
as an hint to awake the semaphore
As a side, there is a potential thread bug
T1 do
* wait sema
* busy = true;
* while (!queue.empty) do work...
* busy = false;
* go back to wait sema
T2 do
* post sema even if busy is false
If T1 stop after the while queue but before the busy, T2 won't post the
event. When T1 will wake up, it will block on the semaphore
Use a relaxed atomic to read the exit variable in the hot path
Wait that exit is deasserted in the destructor, so we are sure the
thread will "soon" return
Value could range from 1 to 9. Default is 4 and it is potentially the
best option. Feel free to test some values on your system, behavior
might depends on the core number and thread number
Value is exponential so 4 is 2 times more pixels than 3.
Small value increased thread overhead, big value increase wait/sync latency
Gregory Hainaut