Comments (9)
OK so as I understand it, net_midi.c is a doubly linked list. The active midi ops in there make a circular linked list structure. The error condition 'error unlinking midi operator' should only ever fire if net_midi_list_remove is called twice on the same midi op.
That should surely never happen - possibly gives another clue to what might be going on...
from aleph.
oy sorry, i didn't see this earlier.
yeah it really looks like ops are being removed twice from the list... this only happens in the op deinit function. could deinit be called twice somehow?
the list managemetn stuff itself is awfully simple.
and yeah, it doesn't need to be doubly linked really.
from aleph.
Just added two commits with some more debug - now I'm getting a crash like this:
chunks per message: 1 , op class: 47 , size: 96 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 6 , size: 84 ; allocating...
chunks per message: 1 , op class: 46 , size: 68 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 6 , size: 84 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 20 , size: 128 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 6 , size: 84 ; allocating...
requested push of midi op already in list - bailing
op creation failed; too many inputs in network.
that 'bail on midi op already in list' was silent in the original code. Needs some more debug on entering/leaving net_midi_list_push & net_midi_list_remove...
from aleph.
yeah.. something funny is happening when add_op
fails... and sequence of events is something like
- get a chunk for the op
- call
op_init
, which callsnet_midi_list_push
- oops, too many ins/outs
- call
op_deinit
which should unlink it from the list again add_op
should exit early before doing anything else- next time a midi op is made, it reuses the chunk address? and it's already linked? that's the part that's weird.
(sorry i know this is obvious, just going through it)
from aleph.
next time a midi op is made, it reuses the chunk address? and it's already linked? that's the part that's weird.
Very weird! In fact I'm going to try printing the hex address of new midi ops - most obvious possibility would be that the new op pool code is playing up, allocating the same memory chunk twice...
It doesn't look like deinit is called twice...
from aleph.
With the mem address printed on every entry to midi_list_push & midi_list_remove:
chunks per message: 1 , op class: 6 , size: 84 ; allocating...
entered net_midi_list_push D0042944
net_midi_list_push exited normally
op creation failed; too many inputs in network.
entered net_midi_list_remove D0042944
net_midi_list_remove exited normally
chunks per message: 1 , op class: 16 , size: 88 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 49 , size: 72 ; allocating...
op creation failed; too many inputs in network.
chunks per message: 1 , op class: 5 , size: 96 ; allocating...
setting monome grid focus, op pointer: 0xD0042944 , value: 1
warning! requested focus, but no handler was set. bad device type maybe?
op creation failed; too many inputs in network.
setting monome grid focus, op pointer: 0xD0042944 , value: 0
chunks per message: 1 , op class: 6 , size: 84 ; allocating...
entered net_midi_list_push D0042944
requested push of midi op already in list - bailing
op creation failed; too many inputs in network.
entered net_midi_list_remove D0042944
If I didn't know better, I'd say there must be a bug in these four lines:
https://github.com/rick-monster/aleph/blob/net-use-malloc/apps/bees/src/net_midi.c#L90-L94
The reason being (again going through it step by step)
- D0042944 gets pushed onto the midi_op_list
- net_add_op_at bails because not enough inputs
- D0042944 gets freed
- net_midi_list_remove exits normally (should pop D0042944 from midi_op_list)
- next time net_midi_list_push gets called with that same memory chunk, D0042944 is still in the op list
Obviously this conclusion makes no sense, those 4 lines look correct!
Gonna write a debug function to print out the entire contents of ml, call it on entry/exit from push/remove midi_op, try & see what's going wrong there...
from aleph.
think I figured out the corner case that was causing this bug!
https://github.com/rick-monster/aleph/commit/0680f00bac21ca697b052d6e7c635310c5c90c19
So the problem with the original code is, what happens if you de-init ml.top when the list is not of length 1? the op to be deleted (ml.top) gets 'squashed out' of the doubly linked list, then ml.top is still left pointing to the disembodied op linked list element that just got deleted!
According to my reasoning on this - this bug must also have been present in the old code before arbitrary op deletion/insertion. (but not dead sure about that) Whatever - anyway now the bug seems to be fixed! This stress test:
Has been running now for over 5 minutes, whereas it would crash out before https://github.com/rick-monster/aleph/commit/0680f00bac21ca697b052d6e7c635310c5c90c19 after only 30s!
from aleph.
yep, that's a bug alright! sorrrry...
from aleph.
Well I somehow doubt that's the only remaining corner-case crash in BEES - there are a lot of lines in there!
from aleph.
Related Issues (20)
- Build aleph-serial -> OSC bridge in pure C HOT 12
- SVF topology review HOT 13
- Make BEES serial protocol less crash-prone
- PD op emulator & patch editor
- Improve BEES' Output Split Feature HOT 1
- Create BEES MAGINC operator
- Make monome grid come up cleanly on boot HOT 2
- Create Param Scaler for Text Labels HOT 2
- BEES pages UI enhancements
- using bfin for graphics HOT 3
- Cheap MIDI interface fails with MIDINOTE operator HOT 24
- optimization flags HOT 3
- CV output glitches HOT 10
- lines unused slew params & 'stuck states' HOT 2
- globalTimescale seems to be getting intermittently banged with random numbers HOT 9
- Release 0.8.0 firmware (modules & BEES)
- lines write head clicks & pops
- SD card formatting details HOT 2
- Lines module crashes when loop < delay
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aleph.