just for the hell of it can you go to my site and download a fresh copy, and install it libraries and all? i can't imagine i uploaded a corrupt version, but who knows? i tried it on two windows 10 machines and all is well..
Printable View
just for the hell of it can you go to my site and download a fresh copy, and install it libraries and all? i can't imagine i uploaded a corrupt version, but who knows? i tried it on two windows 10 machines and all is well..
completely uninstalled eehack and cleaned registry then rebooted. re downloaded and installed beta 4 from your site 10:20pm est usa. still wanting to freeze on startup but i can click on the modules and they will launch while its still trying to freeze up. as can be seen by the screenshots the mem usage going up
Attachment 10219Attachment 10220
so weird! i wonder what's different
i'll investigate further
This is actually pretty awesome that you've done this. I've thought about how great it would be to be able to create modules for eehack quite a few times. compiling now!
compiled without errors. :)
couple of things, the analysis module's titlebar is named "form", and I can't select wideband for analysis. It's configured under settings and the data is there in the log.
was having some font issues too, but turned out it was something that I did.
mr. jthompson:
so far, i'm stumped!
so if you don't mind helping me debug a bit, here's a special (temporary) release that breakpoints the entire startup process with dialogs. it'll ask you to press OK to continue each step of the startup process.
since the only evidence we have is the fact it starts leaking memory like hell, hopefully you can watch the task manager and see at which stage stuff goes completely haywire, and i can focus on that section.
thanks in advance for your help and your patience
see attached
one thing that also might be helpful if this fails is letting me remote desktop in and test some crap, if you trust me. I could do it while you sleep, you could wake up with a working eehack ....
im trying it on computers at work today and still can't make it flunk so your computer is an important test case
well i copied the debug eehack into the eehack directory, then started eehack, memory usage is low till i hit ok at "start acq thread" then mem usage starts to skyrocket.
Attachment 10228Attachment 10229Attachment 10230
ok that's helpful. the thread must be locking up for some reason in an infinite loop or a race condition...
thing is until you try to connect, the thread should stay idle, just waiting for a connection. i can't see anything that would lock up....
well i found this app for windows,its free, process monitor 3.2
https://technet.microsoft.com/en-us/...rnals/bb896645
i made a log to see if it can help out some, its zipped up.
by looking at that log. when i pressed ok to start acq thread... it put this in the log C:\Program Files (x86)\EEHack\accessiblebridge FAST IO DISALLOWED
Attachment 10234
maybe its looking for "accessiblebridge" which is not in the eehack directory
i use process monitor too, its great.
anyway nice try! but acessablebridge is a windows disk caching mechanism. all that means is it tried to read the disk and the item it requested isn't cached; any program you run in it is likely to produce a similar error.
on my end of things i use visual c++'s debugger with breakpoints, but that's easy to reproduce.
im sure its a race condition or something like that.
just for fun please try this attachment, i relaxed locking and delayed acq thread starting until the ui is fully loaded. theoretically none of that should matter but who knows?
still the same with that test also. what other ways can we go about debugging this?
working on that.. i'd like to avoid true remote debugging as its a bitch to get working
try this.......... i inserted a crapload of debug strings and it opens the debug window on load. hopefully it finds something.
When flashing with the newest beta. Whenever I flash I can never get rid of the flash subroutine window. Doesn't matter if it succeeds or fails It doesn't exit. It leaves fullscreen, but I can't move it or exit it. Otherwise looking pretty good, so far just that and the inability to analyze wideband cruising are the only issues I've had.
if that's all that's broken, i'm shocked!Quote:
When flashing with the newest beta. Whenever I flash I can never get rid of the flash subroutine window. Doesn't matter if it succeeds or fails It doesn't exit. It leaves fullscreen, but I can't move it or exit it. Otherwise looking pretty good, so far just that and the inability to analyze wideband cruising are the only issues I've had.
there's now a huge signalling mess that deals with almost every inter-module function and i'd broken the signal between the flash window and main window that tells it to close, and the signal from the settings dialog to the analyzer that tells it that the wideband config has been updated.
both of those were temporary derps that are fixed now. will upload the changes soon.
edit: i committed them to git anyway, among other small fixes.
this is the heart of the "acquisition thread" (actually just the thread that talks to the ECM),
between the thread and the user interfaces, a qt signalling system...
and between interfaces and the acqthread, a self-locking array of switches, integers, and other parameters...Code:connect(acqthread,SIGNAL(new_packet_ready(packet*)),mode4controller,SLOT(recieve_new_packet(packet*)));
connect(acqthread,SIGNAL(display_critical_error(QString)),this,SLOT(recieve_critical_error_msg(QString)));
connect(acqthread,SIGNAL(new_packet_ready(packet*)),datalog_win,SLOT(recieve_new_packet(packet*)));
connect(acqthread,SIGNAL(update_pktrate(float)),datalog_win,SLOT(recieve_new_pktrate(float)));
connect(acqthread,SIGNAL(connection_state_changed(int)),datalog_win,SLOT(recieve_connection_state(int)));
connect(acqthread,SIGNAL(updated_ecm_info()),datalog_win,SLOT(recieve_new_ecm_info()));
connect(acqthread,SIGNAL(connection_state_changed(int)),this,SLOT(recieve_connection_state(int)));
connect(acqthread,SIGNAL(error_occurred()),this,SLOT(add_fail_count()));
connect(acqthread,SIGNAL(invalid_serial_port()),this,SLOT(recieve_invalid_serial_port()));
connect(acqthread,SIGNAL(new_cylbalance_result(int,int,float)),test_window,SLOT(display_cylbalance_result(int,int,float)));
connect(acqthread,SIGNAL(new_cylbalance_progress(QString,int)),test_window,SLOT(display_cylbalance_progress(QString,int)));
connect(acqthread,SIGNAL(flash_write_successful()),flash_launcher_win,SLOT(remember_previous_bin_write()));
connect(acqthread,SIGNAL(flash_read_successful()),flash_launcher_win,SLOT(save_read_bin()));
connect(acqthread,SIGNAL(end_flashprogress()),this,SLOT(hide_flash_progress()));
connect(acqthread,SIGNAL(start_flashprogress()),this,SLOT(show_flash_progress()));
connect(acqthread,SIGNAL(update_tside_progress(int)),flash_progress_win,SLOT(recieve_tside_progress(int)));
connect(acqthread,SIGNAL(update_eside_progress(int)),flash_progress_win,SLOT(recieve_eside_progress(int)));
connect(acqthread,SIGNAL(new_flash_message(QString)),flash_progress_win,SLOT(recieve_message(QString)));
connect(acqthread,SIGNAL(new_flash_divider(QString)),flash_progress_win,SLOT(recieve_divider(QString)));
connect(acqthread,SIGNAL(new_flash_error(QString)),flash_progress_win,SLOT(recieve_error_message(QString)));
connect(acqthread,SIGNAL(flash_error_occurred()),flash_progress_win,SLOT(error_occurred()));
connect(acqthread,SIGNAL(enable_flash_exit(bool)),flash_progress_win,SLOT(recieve_cancel_enable(bool)));
connect(acqthread,SIGNAL(update_flash_speed(float)),flash_progress_win,SLOT(recieve_flash_speed(float)));
connect(acqthread,SIGNAL(custom_log_append(QString)),raw_command_window,SLOT(new_custom_log_entry(QString)));
connect(acqthread,SIGNAL(connection_state_changed(int)),raw_command_window,SLOT(recieve_connection_state(int)));
connect(acqthread,SIGNAL(acq_event_display(QString)),this,SLOT(display_acqstatus(QString)));
connect(acqthread,SIGNAL(reset_error_count()),this,SLOT(reset_error_count()));
Code:class datastream_control : public QObject {
Q_OBJECT
public:
datastream_control();
safe_switch connection;
safe_switch quit;
//-------------
bool is_connected(); // is completely connected?
bool is_disconnected(); // is completely disconnected?
safe_int connection_state;
//-----------------
ecm_info_header info;
//-------------
safe_string port_name; // serial port string
//-------------
safe_switch mode1msg[8];
safe_switch mode1speedhack;
//-------------
safe_switch cyldroptest;
safe_switch blmcell_dump;
safe_switch clear_dtc;
safe_switch ecminfo;
//-------------
safe_switch set_vin;
safe_switch set_calid;
//-------------
safe_int throttle_ms;
//-------------
safe_raw_command custom_a;
safe_raw_command custom_b;
//-----------------
// Mode4 commands
safe_switch mode4send;
void m4_comm_init(); // zero entire mode4 string (disable all hacks)
void m4_comm_afr(byte afr); // command an AFR
void m4_drop_cyl(int cyl); // drop a cyl or 0 = dont drop
void m4_comm_idle(int rpm, int mode); // command an idle, mode 1=rpm 2=steps
void m4_comm_spark(int advance, int absolute); // command a spark, absolute =
int m4_get_spark();
void m4_force_blm(bool set, bool enable);
void m4_force_cl(bool set, bool enable);
void m4_reset_blm(bool set);
void m4_clear_blm_reset(); // this doesn't do an m4 update request for event loop use
void m4_force_gear(int gear); // commanded gear or 0=disable
void m4_fan(int n, bool set, bool enable); // mode::0=auto,1=on,2=off n::1=fan1 2=fan2
void m4_ccp(bool set, bool enable);
void m4_air(bool set, bool enable);
void m4_ac(bool set, bool enable);
void m4_tcc(bool set, bool enable);
void m4_actuator(int enable_byte, int enable_bit, int actuator_byte, int actuator_bit, bool set, bool enable);
QString m4_getpkt();
void m4_get_raw(byte *buf);
void m4_set_raw(byte *buf);
//-----------------
void reset();
safe_switch start_flash_write;
safe_switch start_flash_read;
safe_switch flash_exit;
safe_switch flash_tside;
safe_switch flash_eside;
safe_switch skip_unused_regions;
safe_switch enable_patches;
safe_switch dump_ram;
//-----------------
bin_file write_bin;
bin_file prev_bin;
bin_file read_bin;
private:
//-----------------
byte cylnum_to_m4ref(int cyl);
byte m4_process_afr(int afr);
//-----------------
QMutex m4_lock;
byte construct_mode4[16]; // mode4 buffer
};
copied over and now i get this error
Attachment 10237
its asking for these files qt5cored.dll , qt5widgetsd.dll , qt5guid.dll , qt5serialportd.dll then abruptly exits
oops my bad. that was a debugging symbol build.. try this one.
its working now:thumbsup:
weird thing though the debug window showed no errors just whats in the screenshot.
Thanks for fixing this for me!
Attachment 10239
.. i didn't fix anything, that i know of..
can you post a copy of the whole debug log?
eehack didnt ask to save the log when i exited. another weird one, i just uninstalled eehack and reinstalled 4.4b2 just for the heck of it and it works now! i think something wonky going on with windows, cant win for losing with windows. Hopefully i didnt burn up to much of your time on a wild goose chase. i dont know whats up with my machine, its damn near bare bones.
eehack doesn't save debug logs, it has a 'copy to clipboard' button instead
i think the line of code in question is the loop delay when it's idling waiting for the ui to request a connection.
i used the mysterious 'serial speed' slider on the settings dialog to set the loop delay as a base for the length of the delay
each loop iteration also updates the status to 'idle' which requires a queued signal
i think somehow yours got set to zero (meaning a 0*3=0 delay), even though that should be impossible, which caused millions of loops per second rather than tens of loops per second, and overran the signal queue, hence our memory leak and eventual crash.
the reason the 'fix' worked is i introduced an extra delay for our 'testing' version just so the debug log would be readable
im just going to use a fixed delay there instead, in fact i might get rid of that serial speed slider, i think it's obselete now anyway.
new beta: http://fbodytech.com/eehack-2/beta/
things still broken that i need to fix before i release a stable version, but can't be bothered:
blm cell memory dump does the query but doesn't display
opening log files via windows or via command line doesn't work (when i fix it, it'll be capable of opening multiple log files in one shot..)
raw commands when disconnected work, but have additional delay time added to them
anything else to add to the list?
any opinions on whether the new user interface design is useable for the time being?
Still having issues with timestamps. I logged a 60 minute drive, and then saved it, as soon as it finished saving the corrupt timestamp message came up. I opened it with an older version of $EEhack, prior to the timestamp check to analyze it. Works fine there. Don't know what's going on with that. I did turn the car off several times, but never stopped logging.
Log file attached.
weird, i'll look into it?
timestamps are done much differently now, the new record is stamped relative to the last record (before it was relative to the first record)
it should also enforce a minimum and maximum timestamp difference since the last record.
that logic was supposed to fix these issues, especially in the event of a disconnect..
the corrupt timestamp means its just not sequential so something broke
It appears that PE AFR analysis is rounding to the nearest whole number in the display.
i'll check that out.
one interesting thing for me to consider is you're the only one running a 64 bit build of this thing, it might be an issue with the size of the timestamp variable that i didn't anticipate. i'll look at that tonight.
fixed PE AFR and a few other analyzer oversights. i just noticed that the idle afr wasn't cleared properly on refresh, so subsequent analysis threw off the idle AFR. PE afr now uses the wideband if it exists at all, not just if it's selected in the other AFR tab, which was my intention in the first place. logically if there's a wideband, you should get wideband PE results even if you're analyzing closed loop, narrowband PE voltage is only a fallback if there's no other data to display.
timestamps?
wellll.. i fixed some type issues...
but turns out eehack's beer fund button can be counterintuitive to good development.
i think i was plastered drunk when i wrote the timestamp restriction code.
so when you stopped your car, the timestamp raised past the maximum threshold.. but my botched code ended up lowering the timestamp instead of just raising it to the limit. i tried to do something dumb with offsets instead of just hitting the limit..
i'll commit the changes in a sec after i test them a bit more
edit: new beta is out on github and fbodytech, try 'er out
cool, all the fixes appear to have worked for me, but somehow display percentages isn't working now under wideband.
Also, could you possibly have it remember the narrowband/wideband selection on cruise analysis? every time I restart the program I have to reselect it.
experiencing some strangeness when using control to try to dial in my idle, messing around with idle speed, timing, afr. sometimes the car starts "doing it's own thing" and I have to disconnect $EEhack to get it to settle back down. I'll do some more testing in this area.
i s'pose i could do that. i'll fix the wideband percentage thing too.Quote:
Also, could you possibly have it remember the narrowband/wideband selection on cruise analysis? every time I restart the program I have to reselect it.
the AFR thing can be pretty sketchy as i make it override BLM, closed loop, do a BLM reset, bunch of other crazy crap to make it work. i plan to disable the feature unless patched, and use a patch to make it behave a bit better.Quote:
do you have a log with wideband data and the afr display hack i can have? i don't seem to have a clean one right now.
timing and idle should be ok though?
the new version should clear all settings when closing the 'controller' window, you shouldn't have to reconnect
it's possible i've missed some stuff, there were a ton of changes and to be completely honest i've only bench tested this stuff, not tested on my actual car yet, so i bet something is broken. let me know what else you can find.
i fixed the analyzer bug, when i rewrote the analyzer as a separate window, i just forgot to move the function over that actually copies the checkbox state for 'percentage' to the appropriate variable in the analyzer structure. threw in a conditional memory on that wideband/narrowband thing for you too, it clears itself if the wideband is ever disabled.
https://github.com/resfilter/eehack/...98126b2c44df6c
i glanced and i think i found the controller bug, due to thread synchronization. under the current scheme it's possible that:
- user sets the 'need to send command' flag
- event loop recognizes the flag
- event loop sends command
- user sets the 'needs to send command' flag again
- event loop goes 'ok, i've sent the command, clear the flag'
in this case your additional command happened in the middle of a send procedure and is discarded. the proper command should be sent on the next iteration anyway, but it could definitely do some weird things where your intended commands lag behind, so even though you select a 900 rpm idle, it's still at 600rpm ....
i've done a minor update to solve it in 99% of cases by clearing the flag immediately as it's taken, and when i get home i'll do some proper locking on that operation to eliminate it completely. fixed a few other functions that might be afflicted as well.
https://github.com/resfilter/eehack/...5ac0b581a31a94
proper fix for mode4 request serialization and locking is on github now and also in beta 7 on my site, http://fbodytech.com/eehack-2/beta/
the 'raw commands' interface had a similar bug that i worked around too
one step closer to stable, but im sure there are other problems i'll run across.
one other odd thing is my car now refuses to do flash read/write but datalogs fine using my 'benchmark netbook' which is an intel atom peice of crap running xp. it fails on the first part of trying to get into diagnostic mode.
but if i plug that same laptop into my bench ECM, it works fine, so i tend to blame my car, or perhaps something is wrong with the serial interface that's haphazardly wired into my dashboard...
hey steveo can you give me a shout on my mobile? five oh four six oh six oh five three two