Segmentation Fault
thechenderson opened this issue · comments
After running bmerawdata.py for more than around 10 minutes the program produces a segmentation fault.
Code is running on a Raspberry Pi 4 on Raspberry Pi OS with Desktop.
Code has also been edited to run via SSH to allow for measuring without a GUI and the same issue occurs.
i also get this error randomly, did you solve this @thechenderson ?
@NathanBusler is it possible to make your bmerawdata.py continue if this errors come ? instead of exiting/crashing so frustrating when you have been logging for hours and this errors comes and you need to start over :(
have u managed to resolve this issue? i'm also facing it
The process runs out of memory, and segment faults.
The solution is to increase the stack/heap size, and optionally allow cores to be created.
This will show your shell current values
ulimit -a
On raspbian the stack default is 8MB
The command below will increase the stack to 32MB
ulimit -s 32768
By default cores are set at 0 size (i.e. not written).
The command below will allow an unlimited sized core file to be written:
ulimit -c unlimited
As shown above these commands apply to the current shell only.
Having fixed the SIGSEGV memory you will still likely have trouble from ssh client time-out (SIGTERM) which also kills the process. And possibly from wireless power saving on the PI - it sleeps by default. To fix it edit /etc/rc.local to disable the wireless power save.
Add a line at the bottom just above the exit(0):
iwconfig wlan0 power off
Regards
Keith
Thanks for the suggestion. I tryed it out but now I'm getting "Segmentation fault core damped". I have an ethernet connection, so no trouble for ssh time-out.
ulimit -a returns following values:
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 28559
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 95
stack size (kbytes, -s) 32768
cpu time (seconds, -t) unlimited
max user processes (-u) 28559
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
It looks like running as sudo resolved an issue but just for a while. After a little bit more than one hour of sampling I get the Segmentation fault again.
Moreover the value read by sensor as sudo look unreal. The humidity is always 100% and the temperature is more then 30 degree of Celsius when the temperature should be around 20. Cant tell regarding other values. When i run the same code not us sudo the sample number is not growing and it fail with the error:
Traceback (most recent call last):
File "bmerawdata.py", line 187, in
bme68x_ai.record_data()
File "bmerawdata.py", line 121, in record_data
rt = hp_step['raw_temperature']
KeyError: 'raw_temperature'
How big is the process getting?
ps -elfy | grep python
The RSS and SZ values are of interest in the 8th and 9th columns. These values (Kbytes) are Resident Set (non-swappable memory) and Size (code + data + stack), and they are usually an underestimate. If the RSS value is getting close to the ulimit stack size then double the ulimit value (or make it unlimited if this is the only process you are interested in). A Pi Zero 2 has around 300MB of free memory once it gets running.
Also what version of BSEC are you running?
BSEC 2.2.0-13
and the value i'm getting running the command u suggested are:
ps -elfy | grep python3
S pi 655 1 0 80 0 29432 12941 poll_s 12:23 ? 00:00:01 /usr/bin/python3 /usr/share/system-config-printer/applet.py
S pi 1178 961 2 80 0 7840 3848 hrtime 12:49 pts/1 00:00:00 python3 bmerawdata.py
S pi 1180 961 0 80 0 584 1837 pipe_w 12:49 pts/1 00:00:00 grep --color=auto python3
it go into segmentation fault almost rigt away. I tried to re-run it and this is what is get:
S pi 655 1 0 80 0 29432 12941 poll_s 12:23 ? 00:00:01 /usr/bin/python3 /usr/share/system-config-printer/applet.py
S pi 1194 633 6 80 0 33636 20373 futex_ 12:52 ? 00:00:06 /usr/bin/python3 /usr/bin/thonny /home/pi/Downloads/bme68x-python-library-bsec2.2.0-13sensors-main/bme68x-python-library-bsec2.2.0-13Sensors/tools/bmerawdata/bmerawdata.py
S pi 1200 1194 1 80 0 20236 10409 pipe_w 12:52 ? 00:00:01 /usr/bin/python3 -u -B -m thonny.plugins.cpython /home/pi/bosh/bme68x-python-library-main/tools/bmerawdata
S pi 1228 1152 0 80 0 580 1837 pipe_w 12:54 pts/2 00:00:00 grep --color=auto python3
something wrong, right?
i tried as well to set the stack size to unlimited o 64, but it is not allowed. Seems like the maximum is 32.
I see you are running the app from an IDE (thonny) and the bmerawdate.py process RSS is ~33.6MBytes.
Not sure how that might impact things but it sure makes it more complex.
bmerawdata.py by default reads the default board file and that default is generated from an earlier v1.5.4 of the Ai-Studio, rather than the v1.7.1 which is the current release. You have to edit bmerawdata.py and change ai_conf = "" to point to your saved board file (.bmeconfig).
I ran "$ python3 bmerawdate.py" and found the RSS value is 7.6Mbytes so close to the default 8MB. I know the process id from the ps (pid = 1103), and increased the stack memory "$ prlimit --stack=unlimited:unlimited -p 1103". The command "$ prlimit -p 1103" will confirm the current values. Below is my output for pid 1103.
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit unlimited unlimited bytes
CORE max core file size 0 unlimited bytes
CPU CPU time unlimited unlimited seconds
DATA max data size unlimited unlimited bytes
FSIZE max file size unlimited unlimited bytes
LOCKS max number of file locks held unlimited unlimited locks
MEMLOCK max locked-in-memory address space 67108864 67108864 bytes
MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes
NICE max nice prio allowed to raise 0 0
NOFILE max number of open files 1024 1048576 files
NPROC max number of processes 1739 1739 processes
RSS max resident set size unlimited unlimited bytes
RTPRIO max real-time priority 0 0
RTTIME timeout for real-time tasks unlimited unlimited microsecs
SIGPENDING max number of pending signals 1739 1739 signals
STACK max stack size unlimited unlimited bytes
As I write this the sample_nr is 538 and counting
I hit Ctrl-C keys and the process wrote the results to a file.
"2023_02_07_22_47_Board_84CCA811FA3C_PowerOnOff_1_63lia0cvtdr8jz18_File_0.bmerawdata"
I can import that data into AI studio and view it as a graph.
P.S. I have yet to collect enough data to sucessfully create a model in AI-Studio.
i tried the suggested by you options to increase the memory only for that process, so I run the py file, found the pid and set it to unlimited. Here my values:
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit unlimited unlimited bytes
CORE max core file size unlimited unlimited bytes
CPU CPU time unlimited unlimited seconds
DATA max data size unlimited unlimited bytes
FSIZE max file size unlimited unlimited bytes
LOCKS max number of file locks held unlimited unlimited locks
MEMLOCK max locked-in-memory address space unlimited unlimited bytes
MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes
NICE max nice prio allowed to raise 0 0
NOFILE max number of open files 1024 1048576 files
NPROC max number of processes 28559 28559 processes
RSS max resident set size unlimited unlimited bytes
RTPRIO max real-time priority 95 95
RTTIME timeout for real-time tasks unlimited unlimited microsecs
SIGPENDING max number of pending signals 28559 28559 signals
STACK max stack size unlimited unlimited bytes
and I still get the segmentation fault right after 38 samples. Pretty few! Running sudo or not it fails.
What type of Pi are you running it on and what version of raspbian?
Could you run " $ vmstat 5 10" and see how much memory is free.
Edit
I connected a pi zero 2 to a display and keyboard to remove the ssh element, and bmerawdata.py threw a SIGSEGV almost instantly, and repeated it every time I ran it. Then I remembered that I rebooted the pi zero and therefore a background python process had started automatically to read and display bme688 data. Stopping the background task has cleared up the SIGSEGV problem - you can't have two python processes accessing the I2C BME688 at the same time. I did alter /boot/config.txt and changed the i2c line to: dtparam=i2c_arm=on,i2c_arm_baudrate=400000 but that did not fix the SIGSEGV.
I am now up to sample 860 and still running, and it SIGSEGV at 1600. I have trapped the zero data return, and I have now run this for several hours. But .... the values look wrong and after I import into AI studio it fails to build a model reporting missing data. So here is the modified bmerawdata-v1-4.py, see if you get something different.
i'm using RPi 400 with Raspbian 10 (buster). i kill all python processes I found. But no luck, still segmentation fault after only 18 measurements (core dump). I turned of also the SSH client I were using to access to RPi from PC and running everything only on RPy terminal. How can I discover that background proccess?
Where did u trap the zero data return?
i have some guess... looks like it fails when one of the objects returned by the library is so when the code performs for hp_step in raw_data, when it comes to it can't understand this value and fails. Do u have an idea how we can fix this?
Where did u trap the zero data return?
If the sensor is not ready it returns null, so I trap that after get_data()
So it was:
for i in range(self.duty_cycle['numberScanningCycles']):
raw_data = self.get_data()
print(raw_data)
and it becomes:
for i in range(self.duty_cycle['numberScanningCycles']):
raw_data = self.get_data()
if raw_data == None or raw_data =={}:
sleep(0.1)
break
print(raw_data)
I also removed the io_task() function and the import of Thread and Lock modules - It looks like Nathan initially looked to use threads but it did not work out so he commented out some lines but left the import and io_task function. Removing this unused code reduces the memory used.
i'm using RPi 400 with Raspbian 10 (buster). i kill all python processes I found. But no luck, still segmentation fault after only 18 measurements (core dump). I turned of also the SSH client I were using to access to RPi from PC and running everything only on RPy terminal. How can I discover that background proccess?
In my case the background process is one I set up. You should look at "$ ps -efly" and see how many python processes are running and check each to see if they use the BME68x library.
ssh is only an issue because my client sleeps and sends a SIGTERM killing the process. Avoiding the SIGTERM using nohup and & is not useful as Ctrl-C is blocked and you can't end recording. I intended to modify bmerawdata.py to end on a timer rather than Ctr-C, but I'm just not sure it is recording anything useful.
If you enable core dumps then you can have a look at what is wrong with gdb
$ gdb /usr/bin/python3 ./core
gdb usually tells you that the python frame has nulls, that is pointers to null which cause the SIGSEGV.
There is more on using gdb here https://wiki.python.org/moin/DebuggingWithGdb
the problem i what it is not able to interpret None... it is NULL and didn-t exist in python... i-m printing the rw data and it is an array of 10 elements ll the time. But from time to time i can see what one of the elements is . And this value is root cause of crash.
changing code as you suggested didn-t help unfortunately. I-m pretty sure it is not a memory leak, but the problem with this NULL value
the problem i what it is not able to interpret None... it is NULL and didn-t exist in python... i-m printing the rw data and it is an array of 10 elements ll the time. But from time to time i can see what one of the elements is . And this value is root cause of crash.
None is a keyword in Python, used to define null or no value. So the code change does trap null data returned by the library.
You could add a print statement to see if/when a null is trapped. So I just rechecked my upload and I messed up and loaded the original version - here is the edited version with the trap for null data. Sorry for the confusion.
In line 142 you need to edit this to reference your board config saved from BME AI-Studio (1.7.1) -
ai_conf = 'default.bmeconfig'
i tried you code but i get always the same values from the sensor
[{'sample_nr': 40, 'timestamp': 635550, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 77.83521270751953, 'gas_index': 0, 'meas_index': 4, 'status': 176}, {'sample_nr': 41, 'timestamp': 635870, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 5194.67333984375, 'gas_index': 1, 'meas_index': 6, 'status': 176}, {'sample_nr': 42, 'timestamp': 637154, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 4417.36279296875, 'gas_index': 2, 'meas_index': 16, 'status': 176}, {'sample_nr': 43, 'timestamp': 641164, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 3252.084228515625, 'gas_index': 3, 'meas_index': 46, 'status': 176}, {'sample_nr': 44, 'timestamp': 641803, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 309.9273681640625, 'gas_index': 4, 'meas_index': 51, 'status': 176}, {'sample_nr': 45, 'timestamp': 642445, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 290.16717529296875, 'gas_index': 5, 'meas_index': 56, 'status': 176}, {'sample_nr': 46, 'timestamp': 643075, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 274.5308532714844, 'gas_index': 6, 'meas_index': 61, 'status': 176}, {'sample_nr': 47, 'timestamp': 643836, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 67.59967803955078, 'gas_index': 7, 'meas_index': 66, 'status': 176}, {'sample_nr': 48, 'timestamp': 644473, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 78.55170440673828, 'gas_index': 8, 'meas_index': 71, 'status': 176}, {'sample_nr': 49, 'timestamp': 645113, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 85.21971130371094, 'gas_index': 9, 'meas_index': 76, 'status': 176}]
it didn-t fail, but it is useless
i tried you code but i get always the same values from the sensor
[{'sample_nr': 40, 'timestamp': 635550, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 77.83521270751953, 'gas_index': 0, 'meas_index': 4, 'status': 176}, {'sample_nr': 41, 'timestamp': 635870, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 5194.67333984375, 'gas_index': 1, 'meas_index': 6, 'status': 176}, {'sample_nr': 42, 'timestamp': 637154, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 4417.36279296875, 'gas_index': 2, 'meas_index': 16, 'status': 176}, {'sample_nr': 43, 'timestamp': 641164, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 3252.084228515625, 'gas_index': 3, 'meas_index': 46, 'status': 176}, {'sample_nr': 44, 'timestamp': 641803, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 309.9273681640625, 'gas_index': 4, 'meas_index': 51, 'status': 176}, {'sample_nr': 45, 'timestamp': 642445, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 290.16717529296875, 'gas_index': 5, 'meas_index': 56, 'status': 176}, {'sample_nr': 46, 'timestamp': 643075, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 274.5308532714844, 'gas_index': 6, 'meas_index': 61, 'status': 176}, {'sample_nr': 47, 'timestamp': 643836, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 67.59967803955078, 'gas_index': 7, 'meas_index': 66, 'status': 176}, {'sample_nr': 48, 'timestamp': 644473, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 78.55170440673828, 'gas_index': 8, 'meas_index': 71, 'status': 176}, {'sample_nr': 49, 'timestamp': 645113, 'raw_temperature': 33.34410858154297, 'raw_pressure': 708.1296997070312, 'raw_humidity': 100.0, 'raw_gas': 85.21971130371094, 'gas_index': 9, 'meas_index': 76, 'status': 176}]
it didn-t fail, but it is useless
The sample_nr values are changing and the raw_gas is changing and the timestamp emitted by the bme688 is updating. I agree the values for Temp, Pressure, and Humidity are rubbish but they always have been. I am still seeing SIGSEGV but not always. I have put my code here: https://github.com/mcalisterkm/p-sensors/tree/master/src/1.3.0.
Update:
I have been running a debug version of the Pi3G code under gdb but it slows things down so much I have yet to see a SIGSEGV when running bmerawdata. The issue of the none-bsec values for temp, pressure, humidity is the main issue now.
Try running the Pi3G forced mode example and it gives BSEC and non-BSEC readings, and the same rubbish values are given for non-BSEC as we have here from bmerawdata. I have run the same sensor with the forced mode example and the adafruit BME680 library example:
Adafruit:
Temperature: 23.0 C
Gas: 7211 ohm
Humidity: 36.3 %
Pressure: 1035.312 hPa
Altitude = -182.08 meters
Pi3G Forced mode
TESTING FORCED MODE WITHOUT BSEC
......
SET HEATER CONFIG (FORCED MODE)
{'sample_nr': 1, 'timestamp': 1921359, 'raw_temperature': 33.23564147949219, 'raw_pressure': 664.9137573242188, 'raw_humidity': 100.0, 'raw_gas': 3285.342041015625, 'status': 160}
TESTING FORCED MODE WITH BSEC
INITIALIZED BME68X
VARIANT BME688
INITIALIZED BSEC
BSEC VERSION: 2.2.0.0
SET BME68X CONFIG
SET HEATER CONFIG (FORCED MODE)
SET BME68X CONFIG
SET HEATER CONFIG (FORCED MODE)
{'sample_nr': 1, 'timestamp': 1927410594762, 'iaq': 50.0, 'iaq_accuracy': 0, 'static_iaq': 50.0, 'static_iaq_accuracy': 0, 'co2_equivalent': 600.0, 'co2_accuracy': 0, 'breath_voc_equivalent': 0.49999991059303284, 'breath_voc_accuracy': 0, 'raw_temperature': 23.009458541870117, 'raw_pressure': 103525.6015625, 'raw_humidity': 37.44693374633789, 'raw_gas': 59040.58984375, 'stabilization_status': 0, 'run_in_status': 0, 'temperature': 18.009458541870117, 'humidity': 50.96482467651367, 'gas_percentage': 0.0, 'gas_percentage_accuracy': 0}
The adafruit (no BSEC) values are very similar to the Pi3G BSEC values for Temp, Humidity, and Pressure, but the Pi3G non BSEC values are way out. All test run within 5 min of each other on the same sensor, note the sensor has not had time to stabilise (iaq_accuracy = 0) but this was just to compare the readings
i figured out my problem of segmentation fault (not sure it is the same for u). I noticed it fails when one of the values in the array returned by the library is as I wrote before. Adding some logs on the terminal I discovered that the library always returns 10 values, but from time to time the gas_index value is duplicated and this creates a NULL value in the returned array. So changing the gas_index in bme68xmodule.c bme_get_data method to the counter which increments every time it's called I managed to avoid this problem so far. Would be interesting to understand why this value is duplicated.
@mcalisterkm i'm actually facing a different issue right now that comes after the one you are trying to fix. By changing the c library code to put inside the list an empty object instead of NULL i managed to avoid the SIGSEGV because i can check for empty values inside the list and skip them. The problem now is that even if all the samples in the .bmerawdata file have the correct timestamp, the bme ai studio seems to be able to read only a portion of the file (like it reads an hour of samples instead of 4). I don't know if this has something to do with the fact that i'm putting empty samples that i then skip, but in the file everything has the correct timestamp and the first and the last samples have a time span between them of the time i expect to be.
Did you face anything like that before?
@mcalisterkm i'm actually facing a different issue right now that comes after the one you are trying to fix. By changing the c library code to put inside the list an empty object instead of NULL i managed to avoid the SIGSEGV because i can check for empty values inside the list and skip them. The problem now is that even if all the samples in the .bmerawdata file have the correct timestamp, the bme ai studio seems to be able to read only a portion of the file (like it reads an hour of samples instead of 4). I don't know if this has something to do with the fact that i'm putting empty samples that i then skip, but in the file everything has the correct timestamp and the first and the last samples have a time span between them of the time i expect to be.
Did you face anything like that before?
Yes I have seen this a lot, where AI Studio rejects large portions of the data, or shows large time gaps. I have not managed to get AI Studio to build a model, it always fails training with data missing messages.
The bmerawdata.py file seems to be based on the Bosch example for Arduino esp8266 /BSEC_2.2.0.0_Generic_Release_30052022/examples/Bosch_BSEC2_Library/examples/bme68x_demo_sample/bme68x_datalogger.cpp.
I am hoping this will change once we fix the data collection issues.
@mcalisterkm i'm actually facing a different issue right now that comes after the one you are trying to fix. By changing the c library code to put inside the list an empty object instead of NULL i managed to avoid the SIGSEGV because i can check for empty values inside the list and skip them. The problem now is that even if all the samples in the .bmerawdata file have the correct timestamp, the bme ai studio seems to be able to read only a portion of the file (like it reads an hour of samples instead of 4). I don't know if this has something to do with the fact that i'm putting empty samples that i then skip, but in the file everything has the correct timestamp and the first and the last samples have a time span between them of the time i expect to be.
Did you face anything like that before?Yes I have seen this a lot, where AI Studio rejects large portions of the data, or shows large time gaps. I have not managed to get AI Studio to build a model, it always fails training with data missing messages. The bmerawdata.py file seems to be based on the Bosch example for Arduino esp8266 /BSEC_2.2.0.0_Generic_Release_30052022/examples/Bosch_BSEC2_Library/examples/bme68x_demo_sample/bme68x_datalogger.cpp.
I am hoping this will change once we fix the data collection issues.
I checked the BME AI studio software in the meantime and i discovered that when training the model you can decide which data to use, Basically it is possible to consider only the gas resistance for the training. So i tried sampling with the fake temperature and humidity values since i'd not use the others inside the training. I sampled for about 4 hours without any issue (i tried sampling for six hours but then i got a segmentation fault due to running out of memory), but when loading the 4 hour long file inside BME AI studio i got only a hour and a half of data shown.
I also checked the format of the file to see if there was something wrong and then i checked manually to see which timestamps where inside the file. The timestamps went from the time when i begun the sampling until the end, and by removing the first hour and a half of samples from the file, laoding it inside the software showed the rest of the data.
I'm stuck here right now because i'm working on another bit right now, but next i want to check if there is a jump in the timestamps that corresponds to where the data is cut out.
I have checked my data files and found no gaps and no missing/extra values. One issue I have found is that samples have a sequence number built into the filename, and this is not changing. The spec in the AI Studio pdf say's that if the sequence number is the same then the session is assumed to be the same - and in my case they are not so AI Studio thinks these are all overflow files from the same recording session. But they are not and not even from the same day. I have not had time to fix this, and we have a new BSEC 2.4.0.0 and a new AI Studio (bmerawdata files have the BSEC version embedded in a header).
I have sucessfully recorded data, generated a neural net model, and used the exported config on a pi to sniff air/ethanol.
And I have an article on it here
The Bosch AI-Studio project, the data, model and the python code are all available.
I did the same thing some time ago by creating a configuration used to sniff air/coffee. Using it with the adafruit board worked fine, usin it on the raspberry pi pico gave me the wrong results instead, always recognizing clean air as a result. Tomorrow i will try your code by using my configuration to see if the raspberry pi recognizes the difference instead.
Hello, I have the same segmentation problem.
I am using raspberry pi zero 2 w, raspbian desktop (32 bit)
BSEC 2.0.6.1
When you compile bmerawdata.py, you take a couple of measurements and you get the segmentation fault. I'm quite desperate since I'm new and nothing I've tried has helped me.
Unfortunately bmerawdata.py has several issues including the output format and naming of sessions do not meet the current BoschSensortec requirements, also the model generation needs a lot of data and a single sensor is not great. The good news is that a trained model does work with this library, and the BoschSensortec devkit with 8 sensors is not too expensive, and idea for data collection.
I have a tutorial here https://github.com/mcalisterkm/teach-your-pi-to-sniff-with-bme688. Which has data, ai model and code, with instructions. Skip the initial steps to collect data with the BoschSensortec dev-board (unless you have it) and pick it up at the AI Studio stage.